[root@node1 ~]# service vsftpd restart
Shutting down vsftpd: [FAILED]
Starting vsftpd for vsftpd: [FAILED]服務啟動失敗，無錯誤日誌輸出，rpm 套件完整。
[root@node1 ~]# netstat -nlap | grep :21
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1289/xinetd發現： TCP 21 埠已被 xinetd (PID 1289) 佔用，導致 vsftpd 無法綁定。
[root@node1 ~]# ls /etc/xinetd.d/
# 若看到 vsftpd 或類似檔案，表示 xinetd 正在代管 FTP 服務# 1. 停止 xinetd
service xinetd stop
# 2. 啟動 vsftpd（獨立模式）
service vsftpd start
# 3. 驗證 vsftpd 正常監聽 21 埠
netstat -nlap | grep :21
# 預期輸出：LISTEN /vsftpd
# 4. (可選) 重新啟動 xinetd（若系統仍需 xinetd 管理其他服務）
service xinetd start 執行結果：
[root@node11 ~]# service xinetd stop
Stopping xinetd: [ OK ]
[root@node11 ~]# service vsftpd start
Starting vsftpd for vsftpd: [ OK ]
[root@node11 ~]# service xinetd start
Starting xinetd: [ OK ]| 項目 | 說明 |
|---|---|
| vsftpd 運行模式 | 預設為 獨立模式，直接綁定 21 埠 |
| xinetd 角色 | 超級守護進程，可代管多個網路服務（如 telnet、ftp、rsync） |
| 衝突原因 | 系統預設安裝同時啟用了 xinetd 管理的 ftp 服務（/etc/xinetd.d/vsftpd 存在），導致 xinetd 先佔用 21 埠 |
| 解決邏輯 | 二選一： ① 讓 vsftpd 獨立運行（推薦，效能較好） → 停用/移除 xinetd 的 ftp 定義 ② 讓 xinetd 代管 vsftpd → 修改 vsftpd.conf 設 listen=NO，由 xinetd 啟動 |
# 1. 移除或停用 xinetd 的 ftp 服務定義
mv /etc/xinetd.d/vsftpd /etc/xinetd.d/vsftpd.disabled
# 或編輯該檔將 disable = yes
# 2. 重新載入 xinetd 設定
service xinetd reload
# 3. 確認 vsftpd 配置為獨立模式
grep "^listen" /etc/vsftpd/vsftpd.conf
# 應為 listen=YES (IPv4) 或 listen_ipv6=YES
# 4. 設定開機自啟
chkconfig vsftpd on
chkconfig xinetd off # 若無其他 xinetd 服務，可關閉netstat -nlap | grep :21 僅顯示 vsftpd 進程service vsftpd status 顯示 runningftp localhost 或 FileZilla 可正常登入、上傳下載| 特性 | 獨立模式 | xinetd 模式 |
|---|---|---|
| 配置關鍵 | listen=YES | listen=NO + xinetd 定義檔 |
| 進程模型 | 單一主進程 fork 子進程處理連線 | xinetd 接收連線再啟動 vsftpd 實例 |
| 效能 | 高（無額外 fork 開銷） | 較低（每連線需啟動進程） |
| 功能支援 | 完整（max_clients、max_per_ip 等） | 受限（部分配置無效） |
| 適用場景 | 高併發、生產環境 FTP 伺服器 | 低頻、多服務共享 xinetd 管理 |
遇到 vsftpd 啟動失敗且無明確錯誤訊息時，首要檢查 21 埠佔用情況。本案例中 xinetd 預設代管 FTP 服務導致埠口衝突，停用 xinetd 代管並確保 vsftpd 以獨立模式運行即可徹底解決。
