本节描述了您的 UUCP 连接可能出现的问题，并建议您在何处查找错误。然而，这些问题都是我凭空想出来的。可能出错的地方还有很多。
在任何情况下，启用 -xall 进行调试，并查看 spool 目录中 Debug 的输出。它应该帮助您快速识别问题所在。此外，我一直觉得在连接失败时打开调制解调器的扬声器很有帮助。对于 Hayes 兼容的调制解调器，可以通过在拨号文件中的调制解调器聊天中添加 ``ATL1M1 OK'' 来实现。
首先应该检查的是所有文件权限是否设置正确。 uucico 应该是 setuid uucp，并且 /usr/lib/uucp、/var/spool/uucp 和 /var/spool/uucppublic 中的所有文件都应该由 uucp 拥有。在 spool 目录中还有一些隐藏文件
也必须由 uucp 拥有。
uucico 一直提示 ``呼叫时间错误'': 这可能意味着在 sys 中的系统条目中，您没有指定详细说明何时可以呼叫远程系统的时间命令，或者您给出的命令实际上禁止在当前时间呼叫。如果未给出呼叫计划，则 uucico 假定永远无法呼叫该系统。
uucico 抱怨站点已被锁定: 这意味着 uucico 在 /var/spool/uucp 中检测到远程系统的锁定文件。锁定文件可能来自先前崩溃或被终止的系统呼叫。但是，也可能存在另一个 uucico 进程正在尝试拨打远程系统并卡在聊天脚本等中。如果此 uucico 进程未能成功连接到远程系统，请使用挂断信号终止它，并删除它留下的任何锁定文件。
我可以连接到远程站点，但聊天脚本失败: 查看您从远程站点收到的文本。如果文本乱码，这可能是速度相关的问题。否则，请确认它是否真的与您的聊天脚本期望的一致。请记住，聊天脚本以 expect 字符串开始。如果您收到登录提示，然后发送您的姓名，但从未收到密码提示，请在发送密码之前甚至在字母之间插入一些延迟。您的速度可能对您的调制解调器来说太快了。
我的调制解调器不拨号: 如果您的调制解调器在 uucico 呼出时没有指示 DTR 线已升高，则您可能没有为 uucico 提供正确的设备。如果您的调制解调器识别 DTR，请使用终端程序检查您是否可以写入它。如果这有效，请在调制解调器聊天的开头使用 E 打开回显。如果在调制解调器聊天期间它没有回显您的命令，请检查您的线路速度对于您的调制解调器来说是否太高或太低。如果您看到回显，请检查您是否禁用了调制解调器响应，或将其设置为数字代码。验证聊天脚本本身是否正确。请记住，您必须编写两个反斜杠才能向调制解调器发送一个反斜杠。
我的调制解调器尝试拨号，但无法拨出: 在电话号码中插入延迟。当从公司内部电话网拨出时，这尤其有用。对于欧洲通常拨打脉冲音的人，请尝试双音多频。在一些国家，邮政服务最近一直在升级他们的网络。双音多频有时会有帮助。
我的日志文件显示我的数据包丢失率极高: 这看起来像是一个速度问题。可能是计算机和调制解调器之间的链接太慢（记住要将其调整到尽可能最高的有效速率）？或者是您的硬件太慢而无法及时处理中断？在串行端口上使用 NSC-16550A 芯片组，据说 38kbps 可以相当好地工作；但是，如果没有 FIFO（如 16450 芯片），则 9600 bps 是极限。此外，您应该确保在串行线路上启用了硬件握手。
另一个可能的原因是端口上未启用硬件握手。 Taylor UUCP 1.04 没有提供打开 RTS/CTS 握手的规定。您必须使用以下命令从 rc.serial 显式启用此功能
我可以登录，但握手失败: 嗯，可能有很多问题。日志文件中的输出应该告诉您很多信息。查看远程站点提供的协议（它在握手期间发送字符串 Pprotlist）。也许它们没有任何共同之处（您是否在 sys 或 port 中选择了任何协议？）。
如果远程系统发送 RLCK，则远程系统上存在您的陈旧锁定文件。如果不是因为您已经通过不同的线路连接到远程系统，请要求删除它。
如果它发送 RBADSEQ，则另一个站点为您启用了会话计数检查，但数字不匹配。如果它发送 RLOGIN，则您无权使用此 ID 登录。