Default services enabled

[Simo Sorce]

On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote:
> On Tue, 23.08.11 11:10, Simo Sorce (simo at redhat.com) wrote:
> 
> > > I am pretty sure that 95% of everybody who has ssd or CUPS installed
> > > will not use it more often than than 1/h, which is really seldom. Hence
> > > I'd make these services socket activated by default (like MacOS does it
> > > too), and for the 5% of machines which use it more often we make it easy
> > > to spawn the daemons on boot. The default should be to make it nice for
> > > 95% of people. The 5% who want to run it unconditionally are probably
> > > knowleadgable admins anyway.
> > 
> > Any chance systemd upstream or Fedora at least will provide a
> > chkconfig-like tool that can give you a very simple intuitive way to
> > completely disable/enable/enable(forced on at boot)/etc... each service
> > in the system ?
> 
> systemctl enable
> systemctl disable
> systemctl mask

No these do not give any simple and intuitive way to deal with systemd
complexities.
Just running 'systemctl' alone gives a list of a truckload of stuff ...
that is generally not really interesting from the pov of knowing what is
eanbled at startup or when.

It basically spits too much output, formats it strangely and gives
information that should be given in a verbose mode only (the
description) as it steals real estate unnecessarily.

> > Systemd unit files are cool and all, but they are also much more
> > difficult to keep track of for admins. With the previous system
> > chkconfig --list gave you an immediate *concise* clear view of the
> > system configuration wrt initialization. Something like that would
> > really be welcome for systemd. Esp when a service has multiple files
> > that need to be changed/unliked/linked at the same time. A tool like
> > that would also show/point out if an action breaks dependencies with a
> > verbose mode view or something.
> 
> systemctl enable/disable will do the right thing for you, if the unit
> files use Also= (which correctly written units do). For example,
> "systemctl disable avahi-daemon.service" will also disable
> "avahi-daemon.socket, since it is listed in Also= in the [Install]
> section of it.

Yeah the enable/disable subcommands are not a problem, the problem is
getting a comprehensive view without having to parse a lot of details
with a single command like chckonfig --list used to do.

> On F16 you can use "systemctl list-unit-files" to get a list of all
> installed unit files with their status, whether they are enabled,
> disabled, statically enabled or otherwise.

Ok, I will check it out once I get an F16 install.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York