Completely Stuck :-(
Hi I'm hoping someone can shed some light on this one, basically I'm convinced amandad never runs from inetd, and I"ve spent days on this so far :-( I'm trying to install Amanda on a Solaris 8 x86 box, where the client and server are one and the same. Installation options were --with- user=amanda, --with-group=sys, --with-amandahosts. /etc/services contains (amongst other things): amanda 10080/udp amandaidx 10082/tcp amidxtape 10083/tcp and inetd has (on one line!): amanda dgram udp wait amanda /opt/local/libexec/amandad amandad If I run the above manually (as root or amanda), the /tmp/amanda/ directory is created, as well as the debug file. So I delete that, kill-HUP inetd just to be safe, and then run amcheck. Nov 24 12:00:27 hostname inetd[168]: [ID 858011 daemon.warning] /opt/local/libexec/amandad: Hangup Nov 24 12:00:28 hostname last message repeated 38 times Nov 24 12:00:28 hostname inetd[168]: [ID 667328 daemon.error] amanda/udp server failing (looping), service terminated amcheck comes up with the timeout error (selfcheck failed) ls -lu on amandad shows it never ran in the first place. So I'm very confused - help! Also I'm not 100% as to what should be going on with .amandahosts, at present I have it in ~amanda, containing 'hostname amanda' and this seems OK. Thanks - John
Re: Completely Stuck :-(
Hi Thanks to Paul and Martin for the advice, although it didn't solve the problem! I thought the indexing services were optional, anyway? - John
Re: Completely Stuck :-(
On Fri, 24 Nov 2000, John Cartwright wrote: >Date: Fri, 24 Nov 2000 09:52:55 -0500 >From: John Cartwright <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Completely Stuck :-( > >Hi > >I'm hoping someone can shed some light on this one, basically I'm >convinced amandad never runs from inetd, and I"ve spent days on this >so far :-( > >I'm trying to install Amanda on a Solaris 8 x86 box, where the client >and server are one and the same. Installation options were --with- >user=amanda, --with-group=sys, --with-amandahosts. > >/etc/services contains (amongst other things): >amanda 10080/udp >amandaidx 10082/tcp >amidxtape 10083/tcp > >and inetd has (on one line!): > >amanda dgram udp wait >amanda /opt/local/libexec/amandad amandad > >If I run the above manually (as root or amanda), the /tmp/amanda/ >directory is created, as well as the debug file. So I delete that, >kill-HUP inetd just to be safe, and then run amcheck. > >Nov 24 12:00:27 hostname inetd[168]: [ID 858011 >daemon.warning] /opt/local/libexec/amandad: Hangup >Nov 24 12:00:28 hostname last message repeated 38 times >Nov 24 12:00:28 hostname inetd[168]: [ID 667328 daemon.error] >amanda/udp server failing (looping), service terminated > >amcheck comes up with the timeout error (selfcheck failed) >ls -lu on amandad shows it never ran in the first place. So I'm very >confused - help! > >Also I'm not 100% as to what should be going on with .amandahosts, at >present I have it in ~amanda, containing 'hostname amanda' and this >seems OK. > >Thanks >- John > -- Joi Ellis [EMAIL PROTECTED], http://www.visi.com/~gyles19/
Re: Completely Stuck :-(
>I'm hoping someone can shed some light on this one, basically I'm >convinced amandad never runs from inetd, and I"ve spent days on this >so far :-( Then it's definitly time to ask :-). >and inetd has (on one line!): > >amanda dgram udp wait >amanda /opt/local/libexec/amandad amandad >... >If I run the above manually (as root or amanda), the /tmp/amanda/ >directory is created, as well as the debug file. So I delete that, >kill-HUP inetd just to be safe, and then run amcheck. > >Nov 24 12:00:27 hostname inetd[168]: [ID 858011 >daemon.warning] /opt/local/libexec/amandad: Hangup This says, as you sort of suspected, that inetd is not able to run amandad for some reason. It is, however listening on the port and so forth, so that part's configured properly. BTW, after it fails like this, inetd will disable the service (that's what it means by "service terminated") for 10 minutes. If you continue to do testing before it re-enables it, nobody will be listening on the port, which will no doubt add to the confusion. Sending inetd a HUP will re-enable everything right away. I know you said the above inetd.conf entry was on one line, but could you confirm absolutely that that trailing "amandad" is really there and is on the same line? That's been a typical problem in the past. When you ran amandad as user amanda, did you give it the full path as in the inetd.conf line? Something like: su amanda -c /opt/local/libexec/amandad And I assume it sat there for 30 seconds then dropped away? If none of this sheds any light, then next entry out of the bag 'o tricks is to write a little shell script like this: #!/bin/ksh exec > /tmp/amandad.out.$$ 2>&1 print "$(date): starting amandad" /opt/local/libexec/amandad print "$(date): amandad done: status is $?" exit 0 Put it in (e.g.) /tmp (it's just for testing, not for production), chmod +x it, then change the inetd.conf line to point at the script instead of directly at amandad. Make sure you leave the trailing "amandad" on the line. The script will run amandad but redirect stdout/stderr to another /tmp file. See if they have anything interesting to say. If the script at least tries to run (e.g. you get the "starting amandad" message) but does not give any more insight, change the call to amandad in the script to: /bin/truss -aelv all /opt/local/libexec/amandad which will dump loads of stuff to stderr. Hopefully one of the last things you see it try to do will point the way to the real problem. >Also I'm not 100% as to what should be going on with .amandahosts, at >present I have it in ~amanda, containing 'hostname amanda' and this >seems OK. That's correct (I assume by "hostname" you mean the name of your server), with the addition that it should be owned by amanda and mode 0600 or 0400. >- John John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Completely Stuck :-(
Hi > This says, as you sort of suspected, that inetd is not able to run > amandad for some reason. It is, however listening on the port and so > forth, so that part's configured properly. Just to be sure: bash-2.03# lsof -i | grep am inetd 19686 root 11u IPv4 0xe1dfac2c0t0 UDP *:amanda (Idle) inetd 19686 root 12u IPv4 0xe26790ec0t0 TCP *:amandaidx (LISTEN) inetd 19686 root 13u IPv4 0xe1c0161c0t0 TCP *:amidxtape (LISTEN) > When you ran amandad as user amanda, did you give it the full path as > in the inetd.conf line? Something like: > > su amanda -c /opt/local/libexec/amandad > > And I assume it sat there for 30 seconds then dropped away? Yeah, works fine > The script will run amandad but redirect stdout/stderr to another /tmp > file. See if they have anything interesting to say. The script won't run from inetd either! It's like some sort of wierd permission problem, except 'root' and 'amanda' can both execute amandad manually. Any ideas? Obviously I'm not getting any debug info at all. I can't think of a reason why inetd would fail in this way ... Thanks - John
Re: Completely Stuck :-(
On Nov 28, 2000, John Cartwright <[EMAIL PROTECTED]> wrote:
> bash-2.03# lsof -i | grep am
> inetd 19686 root 11u IPv4 0xe1dfac2c0t0 UDP *:amanda (Idle)
See, it's not (LISTEN), which means inetd has disabled the service
because of a previous failure. kill -HUP it and see if the state
changes.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Completely Stuck :-(
>Just to be sure: > >bash-2.03# lsof -i | grep am >inetd 19686 root 11u IPv4 0xe1dfac2c0t0 UDP *:amanda (Idle) That's what my system looks like, too. To make my day and contradict Alexandre :-), lsof does not appear to report UDP ports as being in LISTEN state. So this looks OK. >The script won't run from inetd either! ... OK, here's the next idea. Instead of running a script, run truss directly by changing the inetd.conf line to this: amanda dgram udp waitbackup /bin/truss amandad -fo /tmp/amandad.truss /opt/amanda/libexec/amandad (adust as needed for paths and user name). This will dump the truss output in /tmp/amandad.truss. >- John John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Completely Stuck :-(
>> bash-2.03# lsof -i | grep am >> inetd 19686 root 11u IPv4 0xe1dfac2c0t0 UDP *:amanda (Idle) > > See, it's not (LISTEN), which means inetd has disabled the service > because of a previous failure. kill -HUP it and see if the state > changes. I hate to disagree with you, but in my experience Solaris always reports UDP ports as idle. For instance, another machine of mine comes up with the following lsof output: syslogd 177 root4u inet 0x609b5240 0t0 UDP *:syslog (Idle) Yet I know for a fact that syslogd is working 100% OK on this box! - John
Re: Completely Stuck :-(
On Nov 29, 2000, John Cartwright <[EMAIL PROTECTED]> wrote:
>> See, it's not (LISTEN), which means inetd has disabled the service
> I hate to disagree with you, but in my experience Solaris always
> reports UDP ports as idle.
I stand corrected. Thank you and JJ for pointing out my mistake.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Completely Stuck :-(
> OK, here's the next idea. Instead of running a script, run truss > directly by changing the inetd.conf line to this: > > amanda dgram udp waitbackup /bin/truss amandad >-fo /tmp/amandad.truss /opt/amanda/libexec/amandad > Hi This didn't work. In fact, on further investigation, *nothing* works from inetd unless its running as root! So although this isn't exactly an Amanda problem, I'd appreciate some troubleshooting tips all the same :-) Thanks - John
Re: Completely Stuck :-(
>... In fact, on further investigation, *nothing* works >from inetd unless its running as root! ... Yikes. After you send inetd a HUP (and wait a minute), is there anything of interest in /var/adm/messages? Do you actually have a user "amanda" (or whatever) defined? Is it local (/etc/passwd) or are you one of those silly NIS people? :-) If none of this helps, the next thing I'd try is starting a truss on inetd itself and making a connection that does not work, then look at that output. >- John John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
