[ports/net/isc-dhcp*] Don't stop DHCP related daemons

[Matthew Seaman]

On 12/09/2010 15:46:18, jhell wrote:
> On 09/12/2010 09:02, Matthew Seaman wrote:
>> On 12/09/2010 07:46:02, Ion-Mihai Tetcu wrote:
>>> And you can't really know if it's a new install or an upgrade.
> 
>> An app like portmaster or portupgrade would be able to know that.  It's
>> an oddity of the ports/pkg system that because 'upgrade' is implemented
>> as 'delete' followed by 'install' that there is difficulty in making
>> that distinction.
> 
>> In fact, portupgrade has a nifty feature you can enable which causes it
>> to run '/usr/local/etc/rc.d/foo start' for any rc scripts installed by a
>> port it is working on.  Which is almost, but not quite, exactly what is
>> wanted; it should issue 'restart' for services already running, or
>> 'start' for services stopped during the upgrade process.
> 
> 
> 
> If someone really wants to go for automation lets not leave it on the
> backs of every user that is involved with ports that offer network
> services but learn how to properly script out periodic(8) runs or a
> cron(8) job to check for the existence of that process.
> 
> Line wrapage:
> */5 * * * * /usr/local/etc/rc.d/rcscript status \
> 		||/usr/local/etc/rc.d/rcscript start
> 
> Or write your own periodic script that makes use of _enable etc... and
> put it in /usr/local/etc/periodic somewhere.

Heh.  BTDT.  Well, almost:

http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/118325

That just reports on any services that should be running and aren't.  It
would be trivial to make it attempt to restart anything that needed
it.

> People may also be interested in this, that I use for personal cron jobs
> that I need to schedule minutely hourly daily and such.
> http://bit.ly/9ODE56
> 
> Perfectly fine that tools like portmaster or portupgrade offer these
> things but lets not forget that its also really easy to figure out what
> services are going to be stopped before you start a upgrade and then
> restart them after using service(8) for example.
> 
> Maybe it would not be such a bad idea to start a framework for a set of
> periodic checks that the user can configure simple by
> 
> # 5 Minute Service checks
> minutely_check_enable="YES"	# Allow disabling all 5 minute checks.
> minutely_check_rcscript_enable="YES" # Enable check for this rcscript.
> 
> # Hourly checks				#
> hourly_check_enable="YES"		# See above
> hourly_check_rcscript2_enable="YES" 	#
> ...
> 
> The rc.subr system should be able to handle this or service(8) by
> calling status and taking appropriate action for each script within an
> hourly_check_*_enable variable.

Hmmm... checking every 5 minutes and automatically restarting anything
not running sounds like a sorcerer's apprentice scenario...

You shouldn't need to check service status that frequently -- a report
once a day will do, unless you've just been fiddling with the system,
when you could just run the daily check by hand and deal with anything
that needs it.  If you've got a service where downtime cannot be
tolerated, that's why things like nagios and daemontools exist -- but
that's overkill much of the time.

	Cheers

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20100912/963e9f90/signature.pgp