Selfcheck request failed

Error Message

Amanda 2.5.0 and later:

 Amanda Backup Client Hosts Check
 --------------------------------
 WARNING: 192.168.15.245: selfcheck request failed: timeout waiting for ACK
 Client check: 1 host checked in 30.097 seconds, 1 problem found

In Amanda 2.4.4 and earlier the error message was worded differently:

AMANDA backup client hosts check
--------------------------------
Warning: selfcheck request timed out.  Host down?
Client check: 1 host checked in 30.051 seconds, 1 problem found

Possible Causes and solutions

This is usually a client configuration error.

Misconfigured inetd/xinetd/daemontools on the client

If amandad was not started, check your inetd/xinetd/daemontools configuration.

• 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.
• If you are building Amanda binaries on your own, make sure the dump user that has been specified at configure-time (--with-user=USERNAME) is listed in the (x)inetd config file.
• Check whether the dump 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.

Use "netstat -a | grep amanda" to verify there is some program listening on the amanda/udp port. Another tool that can used for verification is lsof.

Unwritable debug directory

Take a look at the amandad debug file on the backup client. Locate the AMANDA_DBGDIR directory (usually /tmp/amanda) and find a file named amandad.DATETIME.debug in the directory. When it starts, amandad will create this file.

If this file does not exist, the Amanda client process, amandad, is not starting properly. Go through the checklist for inetd/xinetd/daemontools above.

It is also possible that the debug directory is not writeable by the dumpuser. Verify the owner and permissions of /tmp/amanda. It should be owned by the user that is specified in (x)inetd and permissions should be 700 (drwx------).

Also check the permissions of the parent directory (usually /tmp: permissions 1777, drwxrwxrwt). If the dumpuser does not have write access in the parent directory, you must create the debug directory yourself, and set ownership/permissions manually.

You may erase the directory and run amcheck again: the directory is created automatically.

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.

Firewall/TCP-wrapper settings

Firewall between backup server and client can cause selfcheck to timeout if the firewall is not configured correctly.

Like most services started from (x)inetd, the TCP-wrapper on the client has to be configured to allow the server to come in.

Failing DNS service

DNS service not available or not working. If client cannot resolve server name then this error message is seen.

Remedy:

• Correct the name resolving issue and make sure client is able to connect to the server.

OR

• Add server name entry in /etc/hosts of client machines.

Diskless Workstation interaction with NIS

(PBI: is this about a Virtual Machine or a Diskless Workstation or simply NIS? Please clarify/fix.)

If your client is a Virtual Machine, and /tmp/ directory is locked/engaged by some process. e.g NIS client of VM fetching NIS server.

Remedy: Stop the NIS service, ensure "ls /tmp" or ls "/var/tmp" responds promptly as other directories, then run amcheck.

---

See more amcheck issues