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