Hello list
I just compiled amanda on a SCO Unix machine (uname -a shows "SCO_SV
shcorp 3.2 5.0.6 i386") and tried to follow instructions to install
it, instructing amanda to back up both of its disks. Everything
appears successful, and the machine passes amcheck tests. When I run
amdump at night, my other linux, freebsd, and windows machines dump
successfully. However on my SCO machine, I get the message:
shcorp.shc /stand lev FAILED [disk /stand offline on
shcorp.shcorp.com?]
shcorp.shc / lev FAILED [disk / offline on shcorp.shcorp.com?]
I've looked in google, and found the following suggestions:
(from faq-o-matic,
http://amanda.sourceforge.net/fom-serve/cache/10.html)
is disk really offline?
Answer appears to be no. After all, I'm using this machine
throughout the day. So I'd assume it should be available for backup,
since no-one touches the machine at night.
filesystem error?
Well, I suppose there *could* be. But the fact that it happens on
both disks seems to indicate that this is not the problem. (I also
installed the same compiled version on a separate sco machine, and
it does the exact same thing).
filesystem too large?
Does not seem to be. /stand is only 15 megabytes, but still fails.
conflicting user name?
Doesn't seem to be it. I configured with user "backup". This only
shows up once in the passwd file, and this box does not have any
external sources for authentication (no nis, ldap, etc)
don't have dump installed?
This isn't it. I compiled by hand, and the config.log shows that
amanda found the dump program. I suppose it could conceivably be
something that amanda doesn't like about SCO's dump program though.
How can I check if this might be the problem?
(from an archived post:
http://groups.yahoo.com/group/amanda-users/message/40200)
permissions on /etc/fstab ok?
On SCO, the file seems to be /etc/mnttab. It is unix mode 644, so
this shouldn't be a problem.
So, I looked at the logs in /tmp/amanda. For the last failed dump, I
see these logs:
-rw------- 1 root backup 231 Jul 22 00:30
killpgrp.20030722043007.debug
-rw------- 1 root backup 231 Jul 22 00:30
killpgrp.20030722043009.debug
-rw------- 1 root sys 2108 Jul 22 00:30
sendsize.20030722003007.debug
-rw------- 1 root sys 2275 Jul 22 00:30
amandad.20030722003005.debug
(strange that these are owned by root instead of backup; is this a
problem?)
sendsize ends with
----------------------------------------------------------------
sendsize[1383]: time 2.300: child 1388 terminated normally
sendsize: time 2.300: pid 1383 finish time Tue Jul 22 00:30:10 2003
----------------------------------------------------------------
Looks ok to me
amandad ends with
----------------------------------------------------------------
amandad: time 4.281: got packet:
----
Amanda 2.4 ACK HANDLE 00E-00A00608 SEQ 1058848217
----
amandad: time 4.281: pid 1382 finish time Tue Jul 22 00:30:10 2003
----------------------------------------------------------------
seems fine, or?
first killpgrp
----------------------------------------------------------------
killpgrp: debug 1 pid 1386 ruid 19 euid 0: start at Tue Jul 22
04:30:07 2003
/usr/local/libexec/killpgrp: version 2.4.4
killpgrp: error [cannot find user root in passwd file]
killpgrp: pid 1386 finish time Tue Jul 22 04:30:07 2003
----------------------------------------------------------------
second killpgrp
----------------------------------------------------------------
killpgrp: debug 1 pid 1389 ruid 19 euid 0: start at Tue Jul 22
04:30:09 2003
/usr/local/libexec/killpgrp: version 2.4.4
killpgrp: error [cannot find user root in passwd file]
killpgrp: pid 1389 finish time Tue Jul 22 04:30:09 2003
----------------------------------------------------------------
Weird errors here. The root user is definitely in the passwd file.
Could this be part of the problem?
Thanks for any ideas on fixing this...
--
Kurt Yoder
Sport & Health network administrator
|
