Let me add to this one. I thought defining use_flock would fix it. However it did not. I then tried lockf, posix_fcntl, and finally lnlock. It looks like it finally works with lnlock. I suspect their is some glibc bug relating to the locking stuff wit this revision of redhat (7.0).
Fingers crossed, but the signs that it will work are looking good. Jon pointed me in the right direction, and with a little bit of trial and error it looks like I will run. Thanks again, regards, Steve Kelly On Thu, 2002-08-01 at 11:23, Stephen Kelly wrote: > 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 > -- ======================= Technical Manager Ilisys Internet Pty Ltd [EMAIL PROTECTED] ======================= New! Ilisys discussion forums http://forums.ilisys.com.au
