[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: enable/disable flags in /etc/default



]] Arthur de Jong 

Hi,

| On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote:
| > Personally, I'd rather we didn't have them, as this is supposed to be
| > controlled by the rcN.d links and if that interface is too hard for
| > people we should fix that rather than invent multiple ways of disabling
| > daemons, but the current mess is, well, a mess.
| 
| I would also love to have a way to easily configure which daemons should
| be started at boot time. I don't know whether switching to insserv made
| things simpler in that regard though.

I think insserv makes it even more complicated, since I believe services might
be pulled in, even if they're disabled.  (Or it might be that insserv
just throws its hands into the air and tells you it doesn't know how to
do something the next time update-rc.d is run.)

| In general I don't like having to mess with /etc/default/foo because it
| also makes it more difficult to start/stop by hand.
| 
| Once nice compromise is what the mldonkey-server package does:
| - /etc/default/mldonkey-server can be used to disable starting at boot,
|   but:
| - /etc/init.d/mldonkey-server force-start still allows manual starting
|   of the service
| - the service is correctly stopped on shutdown

While the UI of this is fairly reasonable, we then have a duplication of
the information on when and if it should be started between the rcN.d
directories and the default file and I think we should try to avoid that
duplication, if possible.

| I would personally really like to see this in most daemons that not
| all users may need all the time. Extra bonus points for having some
| convention for option names.

This is my point: everything or nothing should have it, not some
in-the-middle approach with random option names, stuff like
DONT_START=yes is just confusing.  You seem to think that everything
should have it, I think using the existing rcN.d interface, while not
ideal, is what we have and should use until we replace it with something
better.

regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


Reply to: