Date: Mon, 31 Oct 2011 17:33:30 +0000 From: Chris Rees <crees@freebsd.org> To: Miroslav Lachman <000.fbsd@quip.cz> Cc: ports@freebsd.org, Dominic Fandrey <kamikaze@bsdforen.de>, Doug Barton <dougb@freebsd.org>, Ed Schouten <ed@80386.nl> Subject: Re: ports/162049: The Ports tree lacks a framework to restart services Message-ID: <CADLo83-6ueie2A3Rs0nk1RJjyoawncy7Gv2G4KrUOy=j52RRcw@mail.gmail.com> In-Reply-To: <4EAE94FF.3070803@quip.cz> References: <20111027091500.GM63910@hoeg.nl> <20111027162715.GB1012@sysmon.tcworks.net> <4EAE401B.2040704@FreeBSD.org> <4EAE5075.6030102@bsdforen.de> <4EAE5E2D.3060209@FreeBSD.org> <4EAE7B59.7010104@bsdforen.de> <4EAE94FF.3070803@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31 October 2011 12:30, Miroslav Lachman <000.fbsd@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 defaul= t >>>>>> 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. =A0The 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 workin= g >>>>> would be a 3-knob system. One knob to always restart the services, on= e >>>>> 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, an= d >>>>> 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 i= s >>> causing more problems than it solves. Hence the discussion. > > Yes, and even if I would like to have possibility to restart some service= s > 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 vot= e >> 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 implementatio= n. >> 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-mes= sage?rev=3D1.2;content-type=3Dtext%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 scri= pt, > send an alert, or for example change some file/directory permissions - re= al > example is courier-authdaemon when used with Postfix for SMTP auth, we mu= st > 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() { > =A0 =A0send notice to operator or write something to logfile > =A0 =A0chmod 0755 /var/run/authdaemond > =A0 =A0restart authdaemon > =A0 =A0execute "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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83-6ueie2A3Rs0nk1RJjyoawncy7Gv2G4KrUOy=j52RRcw>