Jukka Salmi -- amanda-users (2008-06-25 12:37:15 +0200):
Hello,
since I upgraded an Amanda installation from 2.4.4p4 to 2.5.2p1, backup
reports always contain lines like these:
FAILURE AND STRANGE DUMP SUMMARY:
amreport: ERROR unexpected log line: 20080625 2 [sec 45.227 kb 41655 kps
When i run spawn amandad via xinetd as root, i get this error.
1214490832.259079: amandad: critical (fatal): running as user root
instead of amandabackup
In the kerberos wiki it says amandad will relinquish root permissions
after reading the keytab. It doesnt seem to be doing that.
Also,
On Thu, Jun 26, 2008 at 8:34 AM, Jukka Salmi [EMAIL PROTECTED] wrote:
I just had a closer look at this problem and it seems to be caused by
a race condition between programs started by Amanda's driver program:
all of these programs (dumper, chunker, taper) and the driver program
itself write
Amanda lock the file while writing to it.
What is the output of: amadmin vv version | grep LOCKING
Which filesystem is used, is it NFS mounted?
Jean-Louis
Jukka Salmi wrote:
Jukka Salmi -- amanda-users (2008-06-25 12:37:15 +0200):
Hello,
since I upgraded an Amanda installation from
Dustin J. Mitchell -- amanda-users (2008-06-26 10:11:54 -0400):
[...]
Unfortunately, that file is basically the intermingled freeform stderr
of just about every process spawned by amdump/amflush, so there's no
single interface through which we can funnel all notifications. The
long-term plan
Jean-Louis Martineau -- amanda-users (2008-06-26 10:12:11 -0400):
Amanda lock the file while writing to it.
What is the output of: amadmin vv version | grep LOCKING
Which filesystem is used, is it NFS mounted?
Hmm, amadmin reveals that
LOCKING=**NONE**
on my system, which probably
Jukka Salmi wrote:
What about using record locking on a file in the logdir (maybe on the
logfile itself)? I.e. making sure that all involved processes always
acquire an exclusive lock, then write the log and afterwards release
the lock?
Amanda already lock the 'log' file.
But why it is not
Chad,
I don't have a krb5 setup and the developers sometimes break it.
amandad relinquish root permissions too soon.
Can you try the attached patch?
Jean-Louis
Chad Kotil wrote:
When i run spawn amandad via xinetd as root, i get this error.
1214490832.259079: amandad: critical (fatal):
Im using the source version 2.6.0p1
Here are the results of the patch.
[EMAIL PROTECTED] amandad-src]# patch amandad.c amanda.patch
patching file amandad.c
Hunk #1 succeeded at 218 with fuzz 2.
Hunk #2 FAILED at 417.
Hunk #3 FAILED at 442.
2 out of 3 hunks FAILED -- saving rejects to file
I realized I could apply this patch by hand based on the diff. I did,
recompiled, and still same result.
Here is the diff for version 2.6.0p1.
[EMAIL PROTECTED] amandad-src]# diff amandad.c amandad.c.orig
221,229c221
if (geteuid() == 0) {
check_running_as(RUNNING_AS_ROOT);
Ian,
Jean-Loiuis provided me with a patch that fixed this problem. The
patch was posted to the list.
I now face a new problem. I need to use my secondary kdc REALM to
authenticate, and not my default realm. The keytab on the server is
from the second kdc realm and the principal is from
11 matches
Mail list logo
