ports/162049: The Ports tree lacks a framework to restart services

Scott Lambert lambert at lambertfam.org
Mon Oct 31 23:30:32 UTC 2011


On Mon, Oct 31, 2011 at 01:30:55PM +0100, Miroslav Lachman wrote:
> For me, it would be nice to be able to define "functions" with whatever 
> content executed on particular action.
> 
> short example:
> 
> function_called_after_upgrade_of_authdaemon() {
>     send notice to operator or write something to logfile
>     chmod 0755 /var/run/authdaemond
>     restart authdaemon
>     execute "self-test" script to check SMTP auth is working
> }
> 
> This in general is more useful than just call restart on installed rc.d 
> script, but ofcourse, it is more complex task to implement and I am not 
> sure, if it should be in ports or in some utility like portmaster.

Would something like the above in the port's rc.d/daemonscript
simplify things for the packages part of the problem space?

If the rc.d scripts had support for an "upgrade" option that defaulted
to doing nothing if the porter didn't put an upgrade function in
his/her ports rc.d/daemonscript, the package scripts and ports
infrastructure could unconditionally call "rc.d/daemonscript upgrade".

Then control of whether or not to do automatic upgrades could be
in /etc/rc.conf right below the "daemon_enable=YES".  

daemon_autoupgrade=NO	# Let the port's rc.d script automagically
                        # handle needed config changes and stop /
                        # restart the daemon when upgraded from pkgs or
                        # ports?

Maybe with a big default cover knob?

autoupgrade_default=NO  # default to allowing ports / pkg tools to
			# auto restart daemons and / or upgrade
			# daemon configurations/databases/...

Would that be a way to make use of our existing automation / config
store infrastructure?  

This would leave the complex logic for each port in the hands of
the porters who are most likely to know what corner cases need to
be treated with care.  Individual porters could automate as much
as they want.  Look at what depends on the current package, say PHP
since it was mentioned before, and see which if any web servers
might need to be restarted, then call the web server's rc.d/daemonscript
(upgrade|restart) as may be appropriate.

Of course, PHP probably won't have a php5_enable=YES in /etc/rc.conf.
But you could still have:

php5_autoupgrade=(YES|NO|WARN|EMAILUPGRADESCRIPTTOADMIN|...)

That could lead to a proliferation of rc.d/scripts which don't
actually control daemons.  That might not be a good thing.  Maybe
using the rc.d scripts is a bad idea?

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert at lambertfam.org



More information about the freebsd-ports mailing list