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

jhell jhell at DataIX.net
Sun Sep 12 20:01:01 UTC 2010

Hash: SHA1

On 09/12/2010 15:10, Matthew Seaman wrote:
> 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...

Right but I'm just thinking of the "X wants Z" scenario but A comes
along and says Y is not even in the picture?... Provide this as a common
ground since the rest would already be done.

But I'm not saying it should even report anything at all unless
something has to be restarted. and heck that could be a option too ;)

> 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.

I agree with that but like you said overkill in most cases and even this
would be overkill in its own way. Providing something like this gives
the user a generic middle-ground where they can make the decision if
they would like something a little more sophisticated or nothing at all.

Not really set in stone but those checks could also obey a *_threshold
much like what 800.zfs-scrub does but for a time-frame instead with
unsaid defaults for the moment.



- -- 

Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the freebsd-ports mailing list