On Tue, 29 May 2001, Scot W. Hetzel wrote:
> From: "Kevin M. Myer" <[EMAIL PROTECTED]>
> > In my logs, I see:
> >
> > May 28 16:00:00 newt inetd[105]: [ID 858011 daemon.warning]
> > /usr/local/libexec/amandad: Hangup
> > May 28 16:00:02 newt last message repeated 38 times
> > May 28 16:00:02 newt inetd[105]: [ID 667328 daemon.error] amanda/udp
> > server failing (looping), service terminated
> >
> It's an inetd problem, apparently when you enable kernel auditing, the
> maximum number of server instances per 60 second interval is lowered for
> inetd. You need to increase this value until inetd stops reporting a
> looping condition.
>
> See your inetd man page for how to set this value.
I'm aware of the inetd limit, which is hard coded at 40 connections per 60
seconds. The syntax for changing that limit is slightly different under
Solaris than Linux which I found out when I tried to change that last week
(you use -r <count> <interval> as an option to inetd as opposed to
{wait,nowait.<count>} but thats not exactly the problem that I'm seeing.
If you do a packet trace, there are only four packets exchanged so forty
amandad's should never be spawned and in this case, I'm only running
amcheck.
What appears to be the problem and which I should have made clearer is
that inetd is not interpretting the return value of the forking child
properly and aparently instead is attempting to spawn forty copies of
amandad. So it is running into the inetd connection limit but its never
actually launching anything.
Incidentally, Amanda works on my Solaris 7 boxen with BSM enabled so I
guess what I should have asked is this:
First, does anyone have Amanda running with Solaris 8 and BSM auditing?
Secondly, if not, would you classify the signalling problem as a Solaris
problem or an amanda problem? I'm pretty certain it is a Solaris problem
but I want to make sure that its not a bug that still allows amandad to
run under less-observed conditions but makes it barf under an audited one
(ala Schrodinger's cats). I'll submit as a bug to Sun - hopefully someone
can confirm this behaviour though.
Kevin
--
Kevin M. Myer
Systems Administrator
Lancaster-Lebanon Intermediate Unit 13
(717)-560-6140
