On Fri, Feb 18, 2000 at 01:38:45AM -0500, James Timberlake wrote:
> actually i do know quite a bit about administering linux. that message came
Well how about you demonstrate it by showing us the analysis you have
made of your problem?
A good admin does as much debugging as they can. They do solid analysis,
they use their knowledge and skill to present the problem as accurately
and non-subjectively as possible. Especially when they rely on the good
graces of people on a mailing list that has only marginal relevance to the
subject.
> off sounding like i have no idea what i'm talking about. it's just that
> this has been driving me nuts and i'm a little worn out. inetd was running;
> just not properly.
And your analysis that it's not "running properly" is?
At the very least you would have run the appropriate commands
to see what port(s) inetd is listening on. Since you would have done that
why not show us?
Assuming you assured yourself that inetd is listening on the 'auth' port,
what debugging info did you get from inetd when it tried to invoke the
program associated with the 'auth' service?
As a good admin you would have at least looked at the manpage of inetd
to see what debugging you could get it to generate for you? Why not
show us that output too?
> tcpserver had taken over and wasn't allowing it to start
What commands and debugging did you do to determine that this is the
case? Can you show us the output? Could you also explain the term
"taken over"? Is it consuming all of your CPU resources? Is it filling
up your disk? Is it logging violently? Is it asking for a ransom?
> any services. also, you can't just "run" inetd.conf as it's a config file
> not a script. i was hoping he could clarify. the only way i know how to
> "run" inetd is to "kill -HUP inetd". what i've decided to do is remove
I'm sorry to say it, but this statement tells us that you may know
something about administering Linux, but you probably don't know a lot
about how it works.
kill sends a signal - it doesn't run anything. There is precisely
one way to run any program on Unix and inetd is no exception. And that
is to feed the path to the kernel via an exec* system call. Typically
done for you by a shell. Eg, as root:
# inetd
> qmail and reinstall it using the tar files instead of the rpms. that way
> i'll have more control over how it works.
I dunno. tar has been known to take over systems too. And to make
matters worse, it's politically motivated!
Mark.
