Date: Sun, 20 Jul 2008 13:14:52 -0400 From: Robert Noland <rnoland@2hip.net> To: Peter Ross <Peter.Ross@alumni.tu-berlin.de> Cc: freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) Message-ID: <1216574092.1887.1.camel@wombat.2hip.net> In-Reply-To: <20080720022644.H23554@oldie.bigpond.com> References: <20080720022644.H23554@oldie.bigpond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-cdChWYDJYrWM8QnZlQ6F
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Sun, 2008-07-20 at 02:32 +1000, Peter Ross wrote:
> [Resending - maybe I used the wrong mail address which is not subscribed=20
> to -current? Does it matter? Anyway, the message did not make it to the=20
> list, it seems, and I did not get a notice.. strange]
> ---------- Forwarded message ----------
> Date: Sun, 20 Jul 2008 01:07:32 +1000 (EST)
>=20
> On Sat, 19 Jul 2008, Robert Noland wrote:
>=20
> > On Fri, 2008-07-18 at 22:19 -0700, Doug Barton wrote:
> > > Bernd Walter wrote:
> > > > Speaking about small systems, where startup time is more a problem =
than
> > > > on 08/15 desktop and server systems.
> > > > What I would love to see is that scripts like moused, ypserv, lpt, =
etc
> > > > are not started if the services are disabled.
> > >=20
> > > That wold be a neat trick, how do you propose we accomplish it? (no,=20
> > > I'm not being snide.)
> > > ..=20
> > > One way you could do this is to have /etc/rc.d/active and=20
> > > /etc/rc.d/inactive (and probably an /etc/rc.d/system for critical=20
> > > stuff that most people shouldn't touch). Then you could have a=20
> > > vipw-like system to allow users to edit rc.conf that would move the=20
> > > scripts to the right directory. Of course, this would be fraught with=
=20
> > > potential for problems. :)
> >=20
> > I almost hate to toss this out there, but what about a sys v type rc?
>=20
> Usually the scripts are running run_rc_command.
>=20
> This does a checkyesno for the rcvar variable which is usually=20
> ${name}_enable. In most of the cases it uses set_rcvar to achieve this.
>=20
> If so, /etc/rc could evaluate ${name}_enable (it already knows them via=20
> /etc/rc.conf) before actually calling a script.
>=20
> There are some irregular names amongst the name of the rcvar variable.
Actually, gnome comes to mind... The gnome_enable option, starts all of
the relevant components of which there are a few...
robert.
> I am not 100% sure whether same of the scripts set ${name}_enable vaiable=
s=20
> implicitly. That could complicate things. I could not find evidence by=20
> browsing through them.
>=20
> I also do not know whether there are scripts that actually do something=20
> valuable before calling run_rc_command.
>=20
> At the moment it looks to me that these excemptions could be dealt with b=
y=20
> adapting the scripts so they meet the standard (running only when=20
> ${name}_enable is set).
>=20
> I only looked through some of the /etc/rc.d scripts en detail (+ some=20
> greps for rcvar etc. in the directory) so it needs some more=20
> investigation.
>=20
> If it works it avoids messing around with symlinks or moving scripts=20
> around, and it reduces the scripts that actually run.
>=20
> As a sys admin I really like the BSD way of having everything relevant to=
=20
> my system in one /etc/rc.conf. It is very convenient.
>=20
> Regards
> Peter
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org=
"
--=-cdChWYDJYrWM8QnZlQ6F
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
iEYEABECAAYFAkiDcowACgkQM4TrQ4qfRONsfwCfRqPh1qlJKr1jXoSL1v1EDR9o
xSMAnjLB4qM6/zGxG4qAiqhEu8YqGoTE
=HZGE
-----END PGP SIGNATURE-----
--=-cdChWYDJYrWM8QnZlQ6F--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1216574092.1887.1.camel>