On Tue, Jul 30, 2002 at 01:39:28PM +0800, Stephen Kelly wrote: > Hello, > I have an issue that is very frustrating with one of my amanda client > machines. I am implementing amanda and adding in live clients one by one > in my datacenter. > > I have three client machines working nicely with amanda so far. They are > backing up to a psuedo autochanger configured on a hard disk partition > on my backup server. This is working nicely while i wait for my new VXA > Autochanger backup device to arrive. > > I have compiled the client software on the troublesome machine. It runs > under xinetd as amanda:disk. The client runs a 2.2.16-22smp kernel and > is based on redhat 7.0 > > amcheck reports no problems. However, when I attempt to rum amdump this > client fails with a problem locking /etc/amandates. > > The error from /tmp/amanda/*size* is. > > sendsize: debug 1 pid 28239 ruid 515 euid 515 start time Tue Jul 30 > 15:32:56 2002 > /usr/local/amanda/libexec/sendsize: version 2.4.3b3 > could not lock /etc/amandates: Invalid argument > sendsize: pid 28239 finish time Tue Jul 30 15:32:56 2002 >
Was this self-compiled? I ask as "locking" is one of the few configure problems I have had. It seems that there are about 5 different file locking schemes from which amanda can choose. And the code in configure is quite complex in deciding if each scheme exists and which is should use. In fact, although I think solaris, my os, has all of the 5 different schemes available, configure occasionally reports there is no file locking mechanism available. Perhaps a scan of the configure results and config.h would reveal which scheme is being used. Or maybe a "make distclean" frollowed by a new run of configure and rebuild might cause it to select a different scheme. It was a long time ago so details escape me, but I recall manually editing config.h before compiling to force amanda on solaris to use a specific locking scheme. > The permissions on /etc/amandates is as follows: > -rw-rw---- 1 amanda disk 0 Jul 26 19:02 /etc/amandates > > I have even tried making this file 0666 to see if that would make a > difference but the same problem occured. There is at least one locking scheme on solaris that requires the set group id bit be turned on, with no execute on, for that file to be lockable. That would be permissions of 2660, -rw-rwS--- (capital S = sgid on, x off). > > The same configuration works fine on an older RedHat based server (RH > 6.x vintage) and on my newer RH 7.3 based servers The same scan of the cache/config files might show which locking schemes are being employed and probably they should all be the same. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road (609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
