[HEADS-UP] systemd for F14 - the next steps

Toshio Kuratomi 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.
> 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.
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
instance, apache):

Requires(preun): systemd
Requires(postun): systemd

# 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
    # corruption.
    /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
well-known units?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100723/9bbb0841/attachment.bin 

More information about the devel mailing list