Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Oct 2011 10:39:03 -0700
From:      Chip Camden <sterling@camdensoftware.com>
To:        ports@FreeBSD.org
Cc:        Ed Schouten <ed@80386.nl>
Subject:   Re: ports/162049: The Ports tree lacks a framework to restart services
Message-ID:  <20111027173903.GC1058@libertas.local.camdensoftware.com>
In-Reply-To: <20111027162715.GB1012@sysmon.tcworks.net>
References:  <20111027091500.GM63910@hoeg.nl> <20111027162715.GB1012@sysmon.tcworks.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--32u276st3Jlj2kUU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoth Scott Lambert on Thursday, 27 October 2011:
> On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
> > Hi folks,
> >=20
> > As crees@ suggested, I'm sending an email to ports@ about this.
> >=20
> > 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.=20
> >=20
> > My question is whether anyone has ever attempted to improve the
> > integration with rc-scripts? In the PR I propose something along these
> > lines:
> >=20
> > 	We know exactly which ports install rc scripts (USE_RC_SUBR).
> > 	Why not run `/usr/local/etc/rc.d/${FOO} status' and
> > 	`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
> > 	on the return value of the first, we can run
> > 	`/usr/local/etc/rc.d/${FOO} start' after installation.
>=20
> 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.
>=20
> 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. =20
>=20
> It could help keep our less sophisticated users from continuing to
> run vulerable versions of software after they think they have done
> what is needed to get the patched software.  The sophisticated users
> would still be free to choose which foot to shoot.
>=20
> A side effect might, eventually, be to encourage ports maintainers
> to analyse their ported software for incompatible config changes
> so that they can programatically halt the install and output a
> warning message before attempting to stop the old daemon then
> upgrading while a likely un-usable config is in place.
>=20
> I see it as win, win, if there is a knob.
>=20
> I do not like either option without a knob, depending on the box
> we are talking about.
>=20

+1 for this idea.

+10 for "The sophisticated users would still be free to choose which foot
to shoot."

--=20
=2EO. | Sterling (Chip) Camden      | http://camdensoftware.com
=2E.O | sterling@camdensoftware.com | http://chipsquips.com
OOO | 2048R/D6DBAF91              | http://chipstips.com

--32u276st3Jlj2kUU
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iQEcBAEBAgAGBQJOqZc3AAoJEIpckszW26+R534IAKfkUdIQtDymWuQ16iMwA110
JUkXqoLMuOdrTQe5CiIECnDzwEch38D8IyBVoq3EDktsVlisliTcBsnLukeFxJdK
HfVpylcGuP+N+UdQbmNF+PIWxAcXqA5XcU9Tyg71s4UXGcDC1K5OwpSD+3uqFR7p
qIkLUqWaOLxEAhYrGqQAqIsi3zbbrK2rRyeLbYpacKox1IZudmUTvIh5eW8+rvwX
hQNYCV7yD9E9QmQSnnXp6Te9Zr7ixFuH/AqTU1I07xcnVVybWcUzyq5K0yYtNo04
7aSiQ8M6GYRGu+Tm1PtKisUG5VdUy1SqVS5bYbRjiheuBoIb+R3ZICL7nGYdsBc=
=MEUn
-----END PGP SIGNATURE-----

--32u276st3Jlj2kUU--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111027173903.GC1058>