這節描述什可以使你的 UUCP 連接出錯，並且建議你在哪兒尋找錯誤。然而,問題被編輯在
我們的頭頂之下。那更能出錯。
在任何情況下,用-xall啟用調試 ,並且看一眼在線軸目錄中調試工具的輸出。它能幫助你快速
認出這個問題出現在哪兒。另外,當它沒聯接時，我總是覺得打開我的調制解調器的揚聲器很有
幫助。用Hayes兼容的調制解調器，這由把“ ATL1M1 OK”加到撥號文件中的調制解調器聊天來
完成。
第一個檢查應該是，所有的文件許可是否正確被設置。 uucico 應該是setuid uucp ，並且在
/usr/lib/uucp ， /var/spool/uucp 和 /var/spool/uucppublic 中的所有的文件應該被uucp
擁有 。這裡也必須有 uucp擁有的線軸目錄中的一些隱蔽的文件。
uucico 不停地說“呼叫時間錯誤”:這可能意味著在 sys 中的系統入口，你沒指定當遠程系統
可以被呼叫時詳細說明的一個時間命令，否則當前你給出了一個實際的禁止呼叫。如果沒有呼叫
時間表被給出， uucico 假設系統從來可以沒被呼叫。
uucico 抱怨地點已經被鎖住: 這意味著uucico 在/var/spool/uucp.中為遠程系統檢測了一個鎖
文件。這個鎖文件可能來自一個更早的到那個毀壞了的系統的呼叫，或被殺死。然而,它也有可能
是，有另外一個位那附近的 uucico 過程正在試著撥遠程系統並且在一個聊天手跡玩不轉了,等
等。如果這個 uucico 進程在與遠程系統聯接時不成功，用一個掛斷信號殺死它，並且移開在它
附近的任何鎖文件。
我能與遠程地點聯接，但是聊天手跡失敗:看你從遠程地點收到的文章。如果它被斷章取義，這可
能是一個聯系速度的問題。否則，確認它確實同意你的聊天手跡。記得,聊天手跡以一個期望行開始。
如果你收到登錄提示符，那發送你的名字，但是從來不會得到口令提示符,在發送它以前，插入一
些延期,或甚至在字母之間。你可能對你的調制解調器來說是太快了。
我的調制解調器不撥號:當uucico呼出時，如果你的調制解調器不顯示DTR 行被提起了，你可能沒把正
確的設備給 uucico 。如果你的調制解調器認出 DTR ，檢查你能寫給它的一個終端程序。如果這個終
端程序工作，在調制解調器聊天開始時打開 E回應。如果在調制解調器聊天期間它不回應你的命令,檢
查你的行速度是否對你的調制解調器是太高或太低了。如果你看見回應，檢查你是否停用了調制解
調器回答，或將他們設置到數字代碼。証實聊天手跡自己是正確的。記住你必須寫兩個反斜線符號，
發送一個到調制解調器。
我的調制解調器試著撥號，但是撥不出去:把延期插入到電話號碼中。當從一個公司的內部電話網撥
號時，這是特別有用的。對在歐洲的人，通常撥脈搏音調,嘗試音頻撥號。在一些國家，郵政的服
務最近一直在升級他們的網。音頻有時有幫助。
我記錄文件說我有極其高的文件損失率:這看起來像一個速度問題。也許在計算機和調制解調器之間
的連接太慢了嗎(記得要使它適應可能的最高效率)？或是你的硬件及時地對服務中斷反應太慢？在你
的連續的端口上的一個 NSC-16550A 芯片組， 38kbps 可以說工作得相當好;然而,沒有 FIFOs (就象
16450 芯片), 9600 bps 是限制。另外,你應該保証硬件握手在連續的行上能被啟用。
另外一個可能的原因是硬件握手不能在端口上被啟用。 Taylor UUCP 1.04 不為在 RTS/CTS 握手上
的開關提供規定。你必須從rc.serial中使用下列命令明確地啟用它：
我能登錄，但是握手失敗:很好,可能有很多問題在那裡。在記錄文件中的輸出應該告訴你很多。看遠程地
點提供什協議(它在握手期間發送行Pprotlist )。也許他們沒有任何共有的東西(你在 sys 或端口選擇
了任何協議嗎?)。
如果遠程系統發送 RLCK ，為你在遠程系統上有一個陳舊鎖文件 。如果不是因為你已經在一個不同的
行上被連結到遠程系統，則要求把它移開。
如果它發送 RBADSEQ ，其他地點有為你被啟動的會話計數檢查，但是數字不匹配。如果它發送 RLOGIN ，
你沒被允許在這個 id 下面登錄。
(http://www.fanqiang.com)
進入【UNIX論壇】
|
![[ 永遠的UNIX::UNIX技術資料的寶庫 ]](/images/title.gif)