Amcheck: selfcheck request timed out: Difference between revisions
Jump to navigation
Jump to search
Paul.bijnens (talk | contribs) (reworked) |
Paul.bijnens (talk | contribs) mNo edit summary |
||
| Line 3: | Line 3: | ||
; Find clues in the debug file of amandad | ; Find clues in the debug file of amandad | ||
* Log into the client, locate the AMANDA_DBG directory (usually /tmp/amanda), and find a file named amandad.DATETIME.debug in there: amandad will create this file whenever it starts. If this file does not exist, amandad is not starting properly. Look for errors in the debug file. | * Log into the client, locate the [[AMANDA_DBG]] directory (usually /tmp/amanda), and find a file named amandad.DATETIME.debug in there: amandad will create this file whenever it starts. If this file does not exist, amandad is not starting properly. Look for errors in the debug file. | ||
* It is also possible that the debug directory is not writeable by the dumpuser. Verify the permissions of /tmp/amanda. You may erase the directory and run amcheck again: the directory is created automatically. Also very the permissions of the parent directory /tmp (usually 1777: drwxrwxrwt). | * It is also possible that the debug directory is not writeable by the dumpuser. Verify the permissions of /tmp/amanda. You may erase the directory and run amcheck again: the directory is created automatically. Also very the permissions of the parent directory /tmp (usually 1777: drwxrwxrwt). | ||
Revision as of 15:53, 9 December 2005
This error can occur under several different situations. First, make sure this problem is reproducible. Usually this is an Amanda client error.
- Find clues in the debug file of amandad
- Log into the client, locate the AMANDA_DBG directory (usually /tmp/amanda), and find a file named amandad.DATETIME.debug in there: amandad will create this file whenever it starts. If this file does not exist, amandad is not starting properly. Look for errors in the debug file.
- It is also possible that the debug directory is not writeable by the dumpuser. Verify the permissions of /tmp/amanda. You may erase the directory and run amcheck again: the directory is created automatically. Also very the permissions of the parent directory /tmp (usually 1777: drwxrwxrwt).
- Misconfigured inetd/xinetd/daemontools
- If amandad was not started, check your inetd/xinetd/daemontools configuration.
- Make sure you set up the correct method.
- Make sure you have added the Amanda services to /etc/services (or the NIS services map).
- Make sure you signalled (x)inetd to reread its configuration (some systems may need rebooting).
- Check the inetd man-page for possible differences between the standard inetd.conf format and the one in your system.
- Pay special attention to typos in inetd.conf; error messages will probably appear in /var/adm/messages or /var/log/messages if you have typed the amandad program name incorrectly.
- Make sure the same user that you have specified at configure-time (--with-user=USERNAME) is listed in the (x)inetd config file.
- Check whether this user has permission to run amandad, as well as any shared libraries amandad depends upon, by running the specified amandad command by hand, as the Amanda user. It should just time-out after 30 seconds waiting for a UDP packet. If you type anything, it will abort immediately, because it can't read a UDP packet from the keyboard.
As soon as you have properly configured (x)inetd config file so as to run amandad, you should no longer get the `selfcheck request timed out' message. Use "netstat -a | grep amanda" to verify there is some program listening on the amanda/udp port. Another nice tools to verify these things is lsof.
- Slow NFS-server
- If Amanda programs are NFS auto-mounted on the client, some clients may fail to mount the Amanda binaries in time for the check.