conf/105568: [patch] Add more flexibility to rc.conf, to choose "_enable" values at startup

[Pietro Cerutti]

Doug Barton wrote:
> What do you feel is the need/benefit of adding this? I read your PR, and
> I don't find your reasoning very compelling. You can easily start or
> stop services after the system enters multi-user mode by simply changing
> the _enable variable and running /etc/rc.d/foo start|stop as needed.
> There are precious few services that depend on being started at boot time.

1) enter multi user mode
2) edit rc.conf
3) /etc/rc.d/foo [start|stop]
vs.
1) choose yes or no before entering multi user mode

It's just a matter of comfort, cleanness and easy of handling.

Here are a few examples which come to my mind right now:

A student having a "web technologies" course would start its web server
and database daemons only during the course.

The same student, during a Linux course would start the kqemu service to
load the Qemu kernel module and run a virtualized linux machine.

An employee would start a VPN connection to its corporation by enabling
vpnc only when working at home.

On a laptop, one could start powerd only when he's running on battery or
when the environment temperature is high (thus CPU clock speed should be
controlled).


> 
> Also, in regards to your section about using this on a laptop, I have
> solved the same problem by using an rc.local script that detects the
> network I'm on and then runs anything I need with onestart. Admittedly
> your solution has the benefit of properly stopping the service at
> shutdown time, but I've never found that to be a problem.

The discussion about the use on laptops is not only related to the
networking facilities.
In the few examples I posted above, I clearly assume that the machine on
which these decisions are taken is a laptop.

I mentioned the use on laptops on the problem report because this is
clearly a matter of mobility.
Moreover, being it a  boot-related patch,  it's not supposed to be used
in a server with hundreds of days of uptime.

> 
> So can you please elaborate on your reasoning? And do others find this
> to be an idea worth pursuing?

Finally, I think that the potential benefits of this patch greatly
exceed its negative effects (if any..).

> 
> Thanks,

Thanks for your feedback!

> 
> Doug
> 


-- 
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20071002/c51b657a/signature.pgp