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