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.
- Kevin
dev_n...@zoho.com wrote:
I don't agree so much.
some time when a system is reboot unnormally, named doesn't have the chance to
remove its pid file.
(when OS is shutdown normally, OS sends SIGTERM to named, named can exit and
remove its own pid file.)
after system is started, the pid number in name's pid file is maybe another
process's.
so kill -0 `cat named.pid` is successful, but named is not running at this time.
Am I right?
> Standard methodology would be to read the contents of the PID file and
> see if that process is running (traditionally kill -0 $pid can be used
> to non-intrusively check whether a given process is running).
>
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
