Selfcheck request failed: Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
No edit summary
(Merged "selfcheck timed out" into this page)
Line 1: Line 1:
; Error Message:
==Error Message==
 
Amanda 2.5.0 and later:


   Amanda Backup Client Hosts Check
   Amanda Backup Client Hosts Check
Line 6: Line 8:
   Client check: 1 host checked in 30.097 seconds, 1 problem found
   Client check: 1 host checked in 30.097 seconds, 1 problem found


Note: Possible causes mentioned below should only be considered if amandad is working on client (pls. check /tmp/amanda/amandad.debug for problems, if is doesnt exists then amandaclient has never run!)<br>
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 [http://freshmeat.net/projects/lsof/ 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.


; Possible Causes (other than amandad not working on client):
===Firewall settings===


1. DNS service not available or not working. If client cannot resolve server name then this error message is seen.
Firewall between backup server and client can cause selfcheck to timeout if the firewall is not configured correctly.
 
===Failing DNS service===
 
DNS service not available or not working. If client cannot resolve server name then this error message is seen.


Remedy:
Remedy:
Line 17: Line 68:
*Add server name entry in /etc/hosts of client machines.
*Add server name entry in /etc/hosts of client machines.


2. 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.
===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:
Remedy:
*Stop the NIS service, ensure "ls /tmp" or ls "/var/tmp" responds promptly as other directories, then run amcheck.
Stop the NIS service, ensure "ls /tmp" or ls "/var/tmp" responds promptly as other directories, then run amcheck.




-----
-----
See more [[amcheck issues]]
See more [[amcheck issues]]

Revision as of 10:00, 27 April 2006

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 settings

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

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