> If named is invoked successfully on startup, then the contents of the
> PID file will be overwritten with the new PID value.
>
> If named *isn't* invoked successfully on startup, then that's a separate
> error condition that should be detected and dealt with, within the whole
> startup subsystem.
>
> The problems with using "ps" to find the named process include:
> -- you can get false matches if you don't tailor your string matching
> _just_right_,
> -- unexpectedly "missed" matches if the command-line arguments change,
> even a little bit (e.g. if someone bypasses the wrapper script on an
> emergency basis to start the process manually, with the arguments given
> perhaps in a different order), and
> -- since "ps" operates on a constantly-changing data source, it can
> "miss" legitimate processes in the process table. I've seen that happen
> many many times with "ps" on Solaris, not sure if Linux or other flavors
> of Unix have some sort of concurrency-control mechanism to prevent that
> phenomenon.
>
I agree all your opitions on ps's drawbacks.
what I said is, kill -0 $PID will return true even the process who owns $PID
isn't named.
for example, named.pid wasn't removed after a system shutdown, the value in it
is 1234.
after system startup, another process is launched and owns that process id of
1234.
so, this start script will not work:
if kill -0 $PID; then
:
else
/usr/local/sbin/named -u nobody
fi
Thanks.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
