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

[Toshio Kuratomi]

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

%post
# Don't do anything.  systemd doesn't require this

%preun
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 || :
fi

%postun
if [ 0$1 -ge 1 ] ; then
    systemctl try-restart httpd.service 
fi

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?

-Toshio
-------------- 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