Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




16.6. Troubleshooting

This section describes what may go wrong with your UUCP connection and makes location suggestions to fix the error. Although these problems are encountered on a regular basis, there is much more that can go wrong than what we have listed.

If you have a problem, enable debugging with –xall, and take a look at the output in Debug in the spool directory. The file should help you to quickly recognize the problem. It is often helpful to turn on the modem's speaker when it doesn't connect. With Hayes-compatible modems, you can turn on the speaker by adding ATL1M1 OK to the modem chat in the dial file.

The first check should always be whether all file permissions are set correctly. uucico should be setuid uucp, and all files in /usr/lib/uucp, /var/spool/uucp, and /var/spool/uucppublic should be owned by uucp. There are also some hidden files in the spool directory which must be owned by uucp as well.[1]

When you're sure you have the permissions of all files set correctly, and you're still experiencing problems, you can then begin to take error messages more literally. We'll now look at some of the more common errors and problems.

16.6.1. uucico Keeps Saying “Wrong Time to Call”

This probably means that in the system entry in sys, you didn't specify a time command that details when the remote system may be called, or you gave one that actually forbids calling at the current time. If no call schedule is given, uucico assumes the system can never be called.

16.6.2. uucico Complains That the Site Is Already Locked

This means that uucico detects a lock file for the remote system in /var/spool/uucp. The lock file may be from an earlier call to the system that crashed or was killed. Another possible explanation is that there's another uucico process sitting around that is trying to dial the remote system and has gotten stuck in a chat script, or stalled for some other reason.

To correct this error, kill all uucico processes open for the site with a hangup signal, and remove all lock files that they have left lying around.

16.6.3. You Can Connect to the Remote Site, but the Chat Script Fails

Look at the text you receive from the remote site. If it's garbled, you might have a speed-related problem. Otherwise, confirm that it really agrees with what your chat script expects. Remember, the chat script starts with an expect string. If you receive the login prompt and send your name, but never get the password prompt, insert some delays before sending it, or even in between the letters. You might be too fast for your modem.

16.6.4. Your Modem Does Not Dial

If your modem doesn't indicate that the DTR line has been raised when uucico calls out, you might not have given the right device to uucico. If your modem recognizes DTR, check with a terminal program that you can write to the modem. If this works, turn on echoing with \E at the start of the modem chat. If the modem doesn't echo your commands during the modem chat, check if your line speed is too high or low. If you see the echo, check if you have disabled modem responses or set them to number codes. Verify that the chat script itself is correct. Remember that you have to write two backslashes to send one to the modem.

16.6.5. Your Modem Tries to Dial but Doesn't Get Out

Insert a delay into the phone number, especially if you have to dial a special sequence to gain an outside line from a corporate telephone network. Make sure you are using the correct dial type, as some telephone networks support only one type of dialing. Additionally, double check the telephone number to make sure it's correct.

16.6.6. Login Succeeds, but the Handshake Fails

Well, there can be a number of problems in this situation. The output in the log file should tell you a lot. Look at what protocols the remote site offers (it sends a string P protlist during the handshake). For the handshake to succeed, both ends must support at least one common protocol, so check that they do.

If the remote system sends RLCK, there is a stale lockfile for you on the remote system already connected to the remote system on a different line. Otherwise, ask the remote system administrator to remove the file.

If the remote system sends RBADSEQ, it has conversation count checks enabled for you, but the numbers didn't match. If it sends RLOGIN, you were not permitted to log in under this ID.



That is, files with names beginning with a dot. Such files aren't normally displayed by the ls command.

  Published under the terms of the Creative Commons License Design by Interspire