On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote: > On Tue, 23.08.11 11:10, Simo Sorce (simo@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
