On Sun, 14 Mar 1999, Lourdes Jones wrote:
>> Hmm, doesn't diald check to see that the PID actually corresponds to a
>> running process?
> No because it normally doesn't create one. That's usually done by the
> init script.
Diald may not read the pidfile, but it definitely creates one. If it
doesn't read the pidfile, perhaps it should.
Diald creates the pidfile (all applications that use a pidfile do,
otherwise they would run into the problems you discuss). Check the man
page for the pidfile option. By default it's /var/run/diald.pid .
>> 1) Diald should check that the diald PID in the pidfile actually
>> corresponds to a running *diald* process
> OK write detection into the init script. :) But note that it happens
> before diald is ever started.
Yes, that's necessary on my system: in the debian init scripts, the the
command "start-stop-daemon --pidfile" is used to check for the existence
of a runnind diald, so my comments about checking to make sure that the
program with the given pid would have to extend to start-stop-daemon as
well (I don't know if they do ... it might add too much complexity to the
s-s-d program).
OK, this strategy is getting a little murkier.
>> 2) If the process is a diald process, make sure it isn't
>> itself (otherwise just touch the pidfile and leave it alone)
> diald is not running yet, it doesn't have a pid number to compare against.
Right, in the case of start-stop-daemon.
>> 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?)
> It didn't create the pid so why should it keep making new ones? I don't
> want to think of the headaches of doing this on a running connection
> session.
Wrong, (at least on my system!). How could another process create a
pidfile for diald, which isn't running yet, without knowing diald's pid?
That's plain impossible. On the other hand, it's crazy to run another
process after diald to find out its pid and create a pidfile (there's no
guarantee of the amount of time that passes between diald starting and the
second process starting and looking for the diald pid ... the period could
be too long, leaving an opening where diald is running but doesn't have
a pidfile).
No, diald is the only process that could create its own pidfile.
I kind of like my strategy 3). Wait a random time, fork, and change the
number in the pid file. It may introduce a race condition while the
pidfile is being changed, though, sigh.
> Note: diald itself seems to ignore pid files altogether. (I've had lots
> of concurrent diald sessions.) This is a initialization script issue.
I suppose diald does not read pidfiles, but it definitely writes them ...
your diald.{options,conf} files for the different diald sessions should
have different pidfile directives, otherwise you may have a problem.
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]
