On Tue, 2011-08-23 at 16:57 +0200, Lennart Poettering wrote: > On Tue, 23.08.11 07:29, Toshio Kuratomi (a.badger@xxxxxxxxx) wrote: > > > > > I think FESCo needs to decide what its policies are wrt on-demand > > > > loading, then we can adjust the Packaging Guidelines appropriately. > > > > > > This is broken IMO ... there is nothing inherently wrong with on > > > demand loading ... actually it is the opposite. (i.e should be done > > > whenever possible). > > > > > On demand loading is great. But the system administrator needs to have > > control to be able to turn things on and off. So we need Lennart to give us > > information on how to do that. > > The same way as for services basically. [Install] sections are used for > all kinds of unit files, not just services. > > > Lennart also needs to give us information on how to write .socket > > files. > > This is probably more of an upstream issue. Writing unit files > downstream is probably not really needed, since socket activation needs > some kind of upstream support. > > > With those in hand, guidelines would and fesco > > would be able to ship with on-demand-loading that was off by default (does > > nt load at all) but the system administrator would be able to enable the > > service so that it would start to load on-demand rather than at boot. > > Hmm? Not sure I can parse your paragraph, but I think we really should > be loading seldom used services by default via socket/device activation, > not on boot. Examples for these services are SSH and CUPS. > > 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 ? 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. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
