Jon, You were right on the money with this one. I reviewed the config.h file, and HAVE_FLOCK was defined as existing, but no locking scheme was defined for use. So I added: #define USE_FLOCK 1
to the config.h file, recompiled, and now the backup is executing normally on the host. Thanks for your help on this one. regards, Steve Kelly On Tue, 2002-07-30 at 18:58, Jon LaBadie wrote: > 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) > -- ======================= Technical Manager Ilisys Internet Pty Ltd [EMAIL PROTECTED] ======================= New! Ilisys discussion forums http://forums.ilisys.com.au
