[HEADS-UP] systemd for F14 - the next steps
a.badger at gmail.com
Fri Jul 23 14:03:27 UTC 2010
On Fri, Jul 23, 2010 at 01:42:03PM +0200, Lennart Poettering wrote:
> On Fri, 23.07.10 07:15, Toshio Kuratomi (a.badger at gmail.com) wrote:
> > > Yes, unless you aks the init system to reload.
> > >
> > So we don't want to do systemd-install enable in most spec files.
> 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.
In Fedora currently, we should really only be using level 1 and level 3 from
above with the current sysVinit guidelines.
> > 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.
Excellent. So is this the proper scriptlets for the common cases? (For
# Don't do anything. systemd doesn't require this
if [ 0$1 -eq 0 ] ; then
# Package removal, not upgrade
# Don't allow errors when stopping service to prevent things like data
/bin/systemctl stop httpd.service >/dev/null 2>&1
/bin/systemctl disable httpd.service > /dev/null 2>&1 || :
if [ 0$1 -ge 1 ] ; then
systemctl try-restart httpd.service
That seems close to what te current guidelines specify for systemVinit
scripts. One thing that I'm not sure of is what happens on reboot after
running "systemctl try-restart". Does "systemctl try-restart" imply
"systemctl enable" and so the program would be started on next reboot? Or
does it not get enabled because try-restart does not hook it into the more
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100723/9bbb0841/attachment.bin
More information about the devel