[Fedora-packaging] Systemd guidelines architectural decisions to be made

[Toshio Kuratomi]

Hey FPC members and members of the general community, decision on
these issues are blocking further work on the systemd guidelines.
Judging from past iterations of the guidelines, this will need
extensive testing to see whether they work for all corner cases (for
instance, I'm pretty sure that the extra try-restart in the trigger
scripts is necessary to make upgrading from sysvinit to systemd
restart a running service but we also need to test that doing so
doesn't have unintended consequences like enabling a stopped service
on the next reboot.  If we decide that we do want to migrat e the
user's configuring of services on or off in particular targets, then
from the sounds of lennarts posts on the ticket we need to also have a
guideline section on how the scriptlets differ for services that are
activated by presence of hardware; whether that's sysadmin overridable
behaviour, etc.]).

-Toshio "who will be out of town for PyCon for a week and doesn't want
the ball to drop on this while he's gone."

On Wed, Mar 2, 2011 at 3:11 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> https://fedorahosted.org/fpc/ticket/31
>
> Okay, we ran out of time at today's meeting so I'm going to post the list of
> architectural decisions FPC needs to decide on in order to keep going on the
> systemd guidelines.
>
> Status report on bugs:
> * I've submitted a patch to notting to fix the chkconfig bug introduced by
>  having chkconfig fallback on calling systemctl:
>  https://bugzilla.redhat.com/show_bug.cgi?id=616857
>  We should be able to use chkconfig --no-redirect in our scriptlets once
>  that's applied
>
> * I've fixed a lot of bugs in the proposed scriptlets and added some notes
>  about other issues discovered to the scriptlets on the guidelines.  Some
>  of those issues lead to the decisions we need to make next:
>
> = Triggers or no triggers =
>
> notting raises the point in the Guidelines ticket that triggers are
> conceptually the right tool for this job.  Additionally, I think that some
> of the things we're trying to do are very difficult without triggers.  For
> instance, telling the difference between a systemv init script that exists
> from an old package versus a systemv init script that exists from a new
> package is not possible just by using chkconfig.  So we can't tell using
> just chkconfig if we are supposed to run a migration from systemv init
> script to systemd or not:
>
> foo-1.0 has only a SysV init script in /etc/init.d/foo
> foo-2.0 has both a SysV init script and a unit file in
> /lib/systemd/system/foo
>
> foo-2.1 has both a SysV init script and a unit file.
>
> If I do yum upgrade foo and it wants to install foo-2.1, how do I know if
> foo-1.0 or foo-2.0 is what is being replaced in %post?  If I don't know,
> then how do I know whether to try to migrate the runlevel information from
> the systemv init script?
>
> If other FPC members feel strongly that we still want to avoid triggers,
> we can try to eliminate each of the corner-case scenarios and see if we can
> avoid them but my present inclination is that triggers are the way to go.
>
> = Migration of user customization =
>
> A lot of the other discussion in the FPC ticket right now is how to migrate
> information about what services are started.  This includes what runlevels
> to migrate and also which commands to use to perform the migrations.  I'll
> list the options that I can think of in a bit but I think the basic question
> is: do we want the user's system settings to just work when they do an
> upgrade or do we want them to start over with our defaults, redoing any of
> their customizations?
>
> == Starting over with the defaults ==
> If the latter, the option that I think works best is to use systemctl enable
> in if the package being upgraded from is a sysVinit user.  Using trigger
> scripts, this would be implemented something like this:
>
> %post
> if [ $1 -eq 1 ] ; then
>    # Initial installation
>    # If a package is allowed to autostart:
>    /bin/systemctl enable foo.service >/dev/null 2>&1 || :
>    # No autostart:
>    # /bin/systemctl daemon-reload >/dev/null 2>&1 || :
> fi
>
> # Note: the NEVR in trigger scripts should all be the version in
> # which the package switched to systemd unit files and the comparision
> # should be less than.  Using <= the last version with the sysV script won't
> # work for several reasons:
> # 1) disttag is different between Fedora releases
> # 2) An update in an old Fedora release may create a newer NEVR
> %triggerun -- foo < 1.0-2
> # Run this because the chkconfig --del in the SysV providing package won't
> # fire unless the package is removed
> /sbin/chkconfig --del bar >/dev/null 2>&1 || :
> # I think that we need this as well
> #     /bin/systemctl try-restart foo.service >/dev/null 2>&1 || :
>
> # If the package is allowed to autostart, do the following
> /bin/systemctl enable foo.service >/dev/null 2>&1
> /bin/systemctl daemon-reload >/dev/null 2>&1 || :
>
> (The %preun and %postun will remain as they are in the current proposal)
>
> In this example, systemctl enable is working similarly to chkconfig --add.
> It looks in the unit file for the Wanted-By entry.  Then it enables the
> service in all of the targets listed there.
>
> === Some thoughts on this ===
> Under this model, it would be most user friendly if we migrated to systemd
> unit files all in one release cycle.  Failing that, it would be user
> friendly to have a policy that pacakgers must not update from sysv to
> systemd scripts over the course of a released Fedora.  The reasoning behind
> either of those rules would be that services may be enabled or disabled when
> a package updates from the systemV to the systemd version so we'd want to
> minimize that happening when the user doesn't expect.
>
> Failing either of those, this will only hit the user once per package that
> they have installed that migrates from sysV to systemd which may or may not
> be acceptable.
>
> == Migrating the user's settings ==
>
> If we do think that we should be migrating the user's settings then we need
> to think about what customizations the user may have performed and how we
> can migrate them to a systemd equivalent.  For the purposes of the
> Guidelines, the user may have turned a service on or off in a particular
> runlevel.  Of the runlevels that system v init provides, there are five that
> have a definite meaning with a map into systemd: 1 => rescue, 3 =>
> multi-user, 5 => graphical, 0 => poweroff, and 6 => reboot.  Of these, 0 and
> 6 don't seem to have any scripts in Fedora that are designed to start there
> so we don't need to migrate anything that the user customized.
>
> The other three can be migrated so that the user can use those targets under
> systemd and have them start the same programs as they did when they were
> using systemv initscripts.  Migrating a service for a particular target
> seems to need to use explicit symlinking; systemctl doesn't appear to have
> a command that does that.  The %triggerun script would look something like
> this (the other scripts stay the same as the previous example):
>
> %triggerun -- foo < 1.0-2
> /sbin/chkconfig --del bar >/dev/null 2>&1 || :
> if chkconfig --level --no-redirect 1 foo ; then
>    ln -sf /lib/systemd/system/foo.service /etc/systemd/system/rescue.target.wants/ 2>&1 >/dev/null
> multiuser=0
> if chkconfig --level 3 foo; then
>    ln -sf /lib/systemd/system/foo.service /etc/systemd/system/multi-user.target.wants/ 2>&1 >/dev/null
>    multiuser=1
> fi
> if chkconfig --level 5 foo; then
>    # If it's already in multi-user, it will be inherited automatically
>    if [ $multiuser -eq 0 ] ; then
>        ln -sf /lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/ 2>&1 >/dev/null
>    fi
> else
>    if [ $multiuser -eq 1 ] ; then
>       # We have the option of disabling the service in graphical here to
>       # match what the user explicitly customized their system to like
>       # this:
>       ln -sf /dev/null /etc/systemd/system/graphical.target.wants/foo.service
>       # But we could also decide that this is not something that we're going
>       # to migrate (as systemd itself sets graphical up as a strict
>       # superset of multi-user).
>    fi
> fi
> /bin/systemctl daemon-reload >/dev/null 2>&1 || :
>
> = Migration between sysv and systemd settings post-package changes =
> Also raised in the ticket is whether we should support moving back to
> sysvinit.  My view on that is that we should allow a user installing and
> customizing a systemVinit system in parallel to the systemd files without
> getting in their way but we shouldn't explicitly support migration from
> the default init system to another init system in the standard packaging
> guidelines.  We can certainly have guidelines for each individual init
> system that people who write scripts for them may follow but setting up
> which runlevel-equivalents each of those start services in should be
> independent of what's being done in systemd.
>
> I think that's the basics of the issues we need to work on to keep moving
> forward on the guidelines.  There's certainly more information and
> informational questions that could be asked and answered to make informed
> decisions here, though.  discuss away.
>
> -Toshio
>