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

[Chris Rees]

On 31 October 2011 12:30, Miroslav Lachman <000.fbsd at quip.cz> wrote:
> Dominic Fandrey wrote:
>>
>> On 31/10/2011 09:37, Doug Barton wrote:
>>>
>>> On 10/31/2011 00:38, Dominic Fandrey wrote:
>>>>
>>>> On 31/10/2011 07:28, Doug Barton wrote:
>>>>>
>>>>> On 10/27/2011 09:27, Scott Lambert wrote:
>>>>>>
>>>>>> On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
>>>>>>>
>>>>>>> What really bothers me when I use the FreeBSD Ports tree on one of my
>>>>>>> systems, is that the behaviour of dealing with services is quite
>>>>>>> inconsistent.
>>>>>>
>>>>>> If all of that is contingent upon a boolean knob the admin can set,
>>>>>> something like NO_RESTART_SERVICES, I suspect everyone could get
>>>>>> what they want and the bikeshed would be limitted to what the default
>>>>>> for that boolean should be.
>>>>>>
>>>>>> The people who don't want the services restarted automagically can
>>>>>> set it and, once things use the new ports framewoork properly, not
>>>>>> have to worry about suprises.  The people who want everything to
>>>>>> restarted as soon as possible can set the knob the other way.
>>>>>>
>>>>>
>>>>>
>>>>> I think Scott's on the right track. The way that I envision it working
>>>>> would be a 3-knob system. One knob to always restart the services, one
>>>>> to never do it; and then asking on a per-port basis, which should be
>>>>> the
>>>>> default. I can imagine portmaster detecting this option in the
>>>>> pre-build
>>>>> phase similarly to how it detects and warns about IS_INTERACTIVE now,
>>>>> and giving the user a menu of options for how to handle it. I'm happy
>>>>> to
>>>>> add more details if people are interested.
>>>>
>>>> I think this should be handled in the pkg-install script. Pkg based
>>>> upgrade tools _do_ exist.
>>>
>>> Yeah, that's what I said below. :)
>>
>> Sorry about that, I read the entire thread in one go, might have
>> overlooked
>> something. Ironic, because the purpose was to avoid posting redundant
>> feedback.
>>
>>>>> Where this actually becomes interesting is not in the ports
>>>>> build/install process, which is pretty easy to deal with, but with
>>>>> package installs/deinstalls. I definitely think it's doable, what we
>>>>> probably want to do is put a knob for this in the port's Makefile, and
>>>>> handle the stop/start for both the port and the package with a little
>>>>> script that can be included in the package, and run with @exec and
>>>>> @unexec.
>>>>
>>>> Note the Porters' Handboock chapter 6.23.1. The knob to stop services is
>>>> already there.
>>>
>>> That feature as it exists currently isn't even close to adequate, and is
>>> causing more problems than it solves. Hence the discussion.
>
> Yes, and even if I would like to have possibility to restart some services
> after upgrade, I really hate this knob to just stop the service and leave it
> stopped. Can somebody add global knob to override this from make.conf?
>
>> Well, I am one of the people who see no need for this feature and my vote
>> is for default off, if it's implemented.
>
> I agree with default off.
>
>> I just wanted to hint that such a function is already in place and I don't
>> think it would be difficult to add the possibility to start a service.
>>
>> What has to be done after an update is often very specific, though.
>> I don't envy the person having to come up with an adequate implementation.
>> E.g. it's not always the service installed by the pkg that needs to be
>> restarted:
>>
>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/automounter/pkg-message?rev=1.2;content-type=text%2Fplain
>
> And that's why I propossed more general user scriptable hooks for
> before/after deinstall - install - upgrade actions. (It is on Doug's
> portmaster proposal list http://dougbarton.us/portmaster-proposal.html)
> Sometimes sysadmin needs more than just restart of the upgraded service.
> Sometimes we need to restart other service as well, or run some test script,
> send an alert, or for example change some file/directory permissions - real
> example is courier-authdaemon when used with Postfix for SMTP auth, we must
> change permissions of socket dir on each upgrade.
>
> 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.
>
> I agree that whatever will be implemented as a result of this discussion, it
> should be optional feature off by default and ports system should not
> silently stop / restart / start services.

Yeah... though I've just remember the BIG reason I never wrote code
for this; pkg_add etc doesn't read or care about /etc/make.conf, so it
has no way of understanding whether to restart the service or not.

Any time we ever add features like this, they're added as @exec lines
etc to the packages, and unless we want to (undesirably IMO) be
grepping make.conf in @exec plist lines, there's no way around that.

tl;dr it'll work fine from the ports side, but until pkgng gets in
there's no way to implement this in packages.

Chris