On Sun, 14 Mar 1999, dizzy wrote:
>> This is normally a good sign that you have a pid file left over from an
>> earlier session. Try a find for diald.pid (on my system that would be
>> /var/run/diald.pid) and delete it.
> Yes that was it. Thanks to all of you for the explanation and help. Ive
> learned something and my diald is starting just fine. I'll keep an eye
> for the stale pids
Hmm, doesn't diald check to see that the PID actually corresponds to a
running process? I imagine this is what's happening: diald starts in the
boot process, obtaining a pid like 70, say. Then it dies on system
shutdown/crash without cleaning up its pid. When you reboot, diald tries
to start, sees the pidfile, checks to see whether that corresponds to a
running process, finds a running process with that number (either itself
or some other boot process ... it's quite likely to have a process with
pid 70 at start-up time) and refuses to start.
I have three suggestions of ways to avoid that scenario (maybe these
already hold, I haven't checked):
1) Diald should check that the diald PID in the pidfile actually
corresponds to a running *diald* process
2) If the process is a diald process, make sure it isn't itself (otherwise
just touch the pidfile and leave it alone)
3) Diald should switch pids after a certain amount of time to get a random
higher pid number which would be less likely to interfere with the boot
process. (Is it possible for a process to change pids without forking?)
Ed
--
Ed Doolittle <mailto:[EMAIL PROTECTED]>
"Everything we do, we do for a reason." -- Peter O'Chiese
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
