On Fri, 23.07.10 07:15, Toshio Kuratomi (a.badger@xxxxxxxxx) wrote: > > Yes, unless you aks the init system to reload. > > > So we don't want to do systemd-install enable in most spec files. Dunno. There are three levels of installation thinkable: 1) on package installation a .service file is placed in /lib/systemd/system, but not otherwise hooked into anything, i.e. it is not made sure it is actviated at startup or any other event. It is left to the user/admin to enable the unit, or even start it. 2) on package installation a .service file is placed in /lib/systemd/system, and "systemctl enable blabla.service" is called, to hook it into one or more well-known units, for example to start it on next boot automatically. It is left to the user/admin to start it after installation if he wants to. 3) on package installation a .service file is placed in /lib/systemd/system, and "systemctl enable blabla.service" is called, and "systemctl start blabla.service" or "systemctl restart blabla.service" is called, which not only hooks the service unit into other units, but also starts it right-away. In Fedora we generally try to avoid level 3, however it might be handy for a few very very low-level daemons, such as udev, possibly. For other distros (such as Debian), which have different policies level 3 might be a more likely choice. Depending on the package in Fedora we'll stick more often to level 1 or 2. > What systemd doesn't provide is an equivalent of the chkconfig add command. > I'm not sure if we don't need that in the systemd world or if it's an > oversight that we need to have added into systemd. What do you think? I don't see why that woulöd be necessary. > Basically what we're trying to replicate is: > > * User can install a service > * That does not enable the service to start, even on the next reboot; other > service asks for the socket, etc. > * However, the init system knows that the service is available for the user > to explicitly turn on. Yupp, that would be level 1 from the list above. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
