Hey, everyone.
I'm starting to get a bit concerned about one aspect of the SysV to
systemd conversion process. I've come across three separate bugs where
the default and/or post-upgrade state of services was incorrect: in two
cases, the service changed from being disabled by default in F15 to
being enabled by default in F16, and in another case, a service went
from being enabled by default in F15 to being disabled by default in
F16. These changes were not intentional, simply mistaken.
Obviously both of these can have major consequences (one of the above
cases broke libvirt networking and certain aspects of NetworkManager,
another prevented sealert from working by default), so I'd ask those
who've migrated their package's services from sysv to systemd to please
double-check their handling of this.
It's pretty simple. This %post snippet enables a service by default:
%post
if [ $1 -eq 1 ] ; then
/bin/systemctl enable foobar.service >/dev/null 2>&1 || :
fi
so *don't put that in* unless your service is actually meant to be
enabled by default. (Remember, you need FESCo's permission for that). If
your service was enabled by default before and is supposed to be enabled
by default now, put that snippet in.
This %triggerun snippet enables a service on upgrade from the
pre-systemd-conversion package:
%triggerun -- %{name} < 1.0-2
/bin/systemctl --no-reload enable foobar.service >/dev/null 2>&1 ||:
(assuming 1.0-2 is the version in which you did the systemd migration).
If your service was enabled by default prior to the conversion,
apparently, you're supposed to put that in: the guidelines page doesn't
attempt to account for the case where a service was enabled by default
but disabled by the user, those users are going to find the services get
enabled again.
Again, *don't put that snippet in* unless your service is meant to be
enabled by default. If it was enabled by default before and is still
supposed to be enabled by default, *do put that snippet in*. Otherwise
the service will go from enabled to disabled when people upgrade.
So: if your service is meant to be enabled by default, put those two
bits in. If it's not, please don't! Thanks.
If you're not sure whether your service was previously enabled by
default or not, look in the header of the SysV service. If it was
enabled by default, you'll see something like this:
# Default-Start: 3 4 5
# chkconfig: 345 26 74
The 'Default-Start: 3 4 5' and 'chkconfig: 345' bits mean the service
was enabled by default on runlevels 3, 4 and 5. (26 and 74 are the
startup / shutdown ordering for the service.) If it wasn't enabled by
default, there'll be no Default-Start line, and the chkconfig line will
have only two blocks, the startup/shutdown ordering definitions.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
