Default services enabled

[Lennart Poettering]

On Tue, 23.08.11 11:56, Simo Sorce (simo at redhat.com) wrote:

> 
> 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.

Hmm? "systemctl enable" usually spits out very little info at all.

Are you referring to "systemctl" without any arguments? That' list you
runtime information about services that are running, or failed.

> > > 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.

systemctl list-unit-files is what you are looking for. It's simpler even
than chkconfig --list.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.