multi-named instance exist?
Rich Goodson
rgoodson at gronkulator.com
Thu Mar 26 13:40:36 UTC 2009
If you're really looking to cover all bases, there's a little gotcha
in Solaris (even in 10) that will make this startup script fail if
it's invoked with sh (as most startup scripts that I've seen are).
The 'test -e' is unavailable in sh on Solaris. You need to use -r
(file exists and is readable) or -f (file exists and is a regular
file) or -s (file exists and has size > 0).
I was burned by this when I first started administering Solaris
machines, as I used to use "if [ -e" all of the time in my shell
scripting. Just one more "issue" that Solaris has, but that's a whole
different mailing list, right there.
-Rich Goodson
Sr. Unix Admin
Mediacom Communications
On Mar 26, 2009, at 1:02 AM, Doug Barton wrote:
> dev_null at zoho.com wrote:
>>
>>
>>> 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.
>
> Boys boys boys .... there is no need to fight, you're both right. :)
>
> NAMED_PID=/path/to/pid
>
> if [ -e "$NAMED_PID" ]; then
> if ps -p `cat $NAMED_PID` | grep named; then
> # named is already running, do what's appropriate
> else
> # pid file is bogus, remove it and start named
> unlink $NAMED_PID
> <start named>
> fi
> else
> if ps -U nobody | grep named; then
> # named is running without a pid file, oops
> <do something useful>
> else
> if ps -ax | grep [n]amed; then
> # something is probably really wrong here
> # probably want to stop and look first
> else
> <start named>
> fi
> fi
> fi
>
>
> I agree with Kevin that ps on Solaris has "issues," although I've
> never had similar problems on FreeBSD I still prefer to try and cover
> all the bases. Limiting the number of processes that you examine with
> ps by looking only at those with user nobody helps limit your chances
> of false positives, although it doesn't cover someone typing 'named'
> as root.
>
> Of course on FreeBSD the /etc/rc.d/named script already handles all of
> this and much more for you. :)
>
>
> Doug
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
More information about the bind-users
mailing list