Default services enabled

[Simo Sorce]

On Tue, 2011-08-23 at 18:14 +0200, Lennart Poettering wrote:
> 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.

Yeah read above: "> Just running 'systemctl' alone ..."

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

Perfect,
thanks!

Simo.

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