Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
1) I don't think the versioned trigger logic will work too well at all in the (not that rare) cases where the previous distro had sysv scripts and one does a version bump in the previous distro - the trigger in the next one will no longer run on distro upgrades because of the versioning. Wouldn't it work better to just drop the version from the trigger altogether, and instead check if the old init script exists? For example:
%triggerun -- httpd [ -e %{_initddir}/httpd ] || exit 0 # rest of the migration stuff goes here
2) Cosmetic: there are unnecessary '|| :'s sprinkled in the scriptlets, only the final exit status of a script has any effect.
3) More or less cosmetic: why hardwire absolute paths everywhere? The vast majority of other scriptlet snippets don't do that.
On 06/03/2011 11:02 PM, Ville Skyttä wrote:
Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
Ping? I think at least 1) below is important enough to be addressed before wider systemd conversion starts to take place.
- I don't think the versioned trigger logic will work too well at all
in the (not that rare) cases where the previous distro had sysv scripts and one does a version bump in the previous distro - the trigger in the next one will no longer run on distro upgrades because of the versioning. Wouldn't it work better to just drop the version from the trigger altogether, and instead check if the old init script exists? For example:
%triggerun -- httpd [ -e %{_initddir}/httpd ] || exit 0 # rest of the migration stuff goes here
- Cosmetic: there are unnecessary '|| :'s sprinkled in the scriptlets,
only the final exit status of a script has any effect.
- More or less cosmetic: why hardwire absolute paths everywhere? The
vast majority of other scriptlet snippets don't do that.
On Fri, Jun 03, 2011 at 11:02:34PM +0300, Ville Skyttä wrote:
Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
- I don't think the versioned trigger logic will work too well at all
in the (not that rare) cases where the previous distro had sysv scripts and one does a version bump in the previous distro - the trigger in the next one will no longer run on distro upgrades because of the versioning. Wouldn't it work better to just drop the version from the trigger altogether, and instead check if the old init script exists? For example:
%triggerun -- httpd [ -e %{_initddir}/httpd ] || exit 0 # rest of the migration stuff goes here
We discussed this when we came up with the guidelines. IIRC, we finally decided this wasn't workable because we don't prevent people from packaging systemVinit scripts (either in subpackages or in a wholly separate package.
I agree with your points about fragility, though. If you can think of a way that handles both I'd be happy to hear it.
- Cosmetic: there are unnecessary '|| :'s sprinkled in the scriptlets,
only the final exit status of a script has any effect.
<nod> I think I'll leave these alone as people don't always understand that.
- More or less cosmetic: why hardwire absolute paths everywhere? The
vast majority of other scriptlet snippets don't do that.
I've replaced /usr/bin with %{_bindir} now. Are there other paths that we could change?
Thanks, and sorry for taking so long to see this, -Toshio
On 06/22/2011 07:24 PM, Toshio Kuratomi wrote:
On Fri, Jun 03, 2011 at 11:02:34PM +0300, Ville Skyttä wrote:
Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
- I don't think the versioned trigger logic will work too well at all
in the (not that rare) cases where the previous distro had sysv scripts and one does a version bump in the previous distro - the trigger in the next one will no longer run on distro upgrades because of the versioning. Wouldn't it work better to just drop the version from the trigger altogether, and instead check if the old init script exists? For example:
%triggerun -- httpd [ -e %{_initddir}/httpd ] || exit 0 # rest of the migration stuff goes here
We discussed this when we came up with the guidelines. IIRC, we finally decided this wasn't workable because we don't prevent people from packaging systemVinit scripts (either in subpackages or in a wholly separate package.
I agree with your points about fragility, though. If you can think of a way that handles both I'd be happy to hear it.
Just a couple of unfiltered thoughts, reader beware; haven't spent much thought or time on these yet:
a) If people do package/have sysv scripts alongside systemd ones, is it desirable to make the systemd migration happen on upgrades in the first place?
b) Maybe checking for existence of the systemd unit file in addition to the sysv script in the above recipe could have some positive properties.
For the packages I migrate to systemd, I don't plan to keep any sysv init scripts around, and the version bump problem would lurk out there ready to bite if I used the currently documented scriptlets. So I'm going to use the sysv script existence check way instead.
- More or less cosmetic: why hardwire absolute paths everywhere? The
vast majority of other scriptlet snippets don't do that.
I've replaced /usr/bin with %{_bindir} now.
That removes the "hardwire" part for a few cases, but doesn't address the "absolute" part.
Are there other paths that we could change?
I'd personally remove all absolute paths to commands in standard PATH from the scripts altogether where possible, macroized or not. The Gconf, GSettings, gdk-pixbuf, GTK+ modules, GIO modules, Scrollkeeper, desktop-database, mimeinfo, and Icon Cache scriptlets and macros are already written without unnecessary absolute paths. The only ones that do contain apparently unnecessary absolute paths are Systemd and Texinfo. Why?
On Fri, Jun 24, 2011 at 01:37:02PM +0300, Ville Skyttä wrote:
On 06/22/2011 07:24 PM, Toshio Kuratomi wrote:
On Fri, Jun 03, 2011 at 11:02:34PM +0300, Ville Skyttä wrote:
Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
- I don't think the versioned trigger logic will work too well at all
in the (not that rare) cases where the previous distro had sysv scripts and one does a version bump in the previous distro - the trigger in the next one will no longer run on distro upgrades because of the versioning. Wouldn't it work better to just drop the version from the trigger altogether, and instead check if the old init script exists? For example:
%triggerun -- httpd [ -e %{_initddir}/httpd ] || exit 0 # rest of the migration stuff goes here
We discussed this when we came up with the guidelines. IIRC, we finally decided this wasn't workable because we don't prevent people from packaging systemVinit scripts (either in subpackages or in a wholly separate package.
I agree with your points about fragility, though. If you can think of a way that handles both I'd be happy to hear it.
Just a couple of unfiltered thoughts, reader beware; haven't spent much thought or time on these yet:
a) If people do package/have sysv scripts alongside systemd ones, is it desirable to make the systemd migration happen on upgrades in the first place?
I'm not sure.... In earlier days when we had other init systems coexisting alongside of sysvinit scripts, we were able to boot with init=/sbin/other_init provided that we had "init scripts" for the services we cared about for the other init system.
If that's still the case we're shooting for, then I think we do want to have migration happen on upgrade.
b) Maybe checking for existence of the systemd unit file in addition to the sysv script in the above recipe could have some positive properties.
I don't think this works.
Lets say you have:
foo-1.0-1 (sysv) foo-1.0-2 (systemd) sysvinit-basescripts-1.0 (which contains sysv init scripts for foo).
We want to perform migration when foo-1.0-2 (or later) replaces foo-1.0-1 but not if the init script is provided by sysvinit-basescripts. This doesn't seem to be predictable based on presence or absence of systemv init scripts and systemd unit files. It's ambiguous whether the presence of a sysvinit script came from the foo-1.0-1 package and therefore means that we're upgrading or if it came from the sysvinit-basescripts package and therefore means we're trying to configure the system to boot with a sysv init system.
For the packages I migrate to systemd, I don't plan to keep any sysv init scripts around, and the version bump problem would lurk out there ready to bite if I used the currently documented scriptlets. So I'm going to use the sysv script existence check way instead.
Unfortunately, this isn't enough as someone providing init scripts for your service in a separate package can ruin detection based on presence or absence of the init script.
- More or less cosmetic: why hardwire absolute paths everywhere? The
vast majority of other scriptlet snippets don't do that.
I've replaced /usr/bin with %{_bindir} now.
That removes the "hardwire" part for a few cases, but doesn't address the "absolute" part.
Are there other paths that we could change?
I'd personally remove all absolute paths to commands in standard PATH from the scripts altogether where possible, macroized or not. The Gconf, GSettings, gdk-pixbuf, GTK+ modules, GIO modules, Scrollkeeper, desktop-database, mimeinfo, and Icon Cache scriptlets and macros are already written without unnecessary absolute paths. The only ones that do contain apparently unnecessary absolute paths are Systemd and Texinfo. Why?
Ah I see -- I tend to agree but I don't know what the other packaging committee members think so I've added it as a ticket for the next meeting:
https://fedorahosted.org/fpc/ticket/96
-Toshio
On 06/22/2011 07:24 PM, Toshio Kuratomi wrote:
We discussed this when we came up with the guidelines. IIRC, we finally decided this wasn't workable because we don't prevent people from packaging systemVinit scripts (either in subpackages or in a wholly separate package.
I agree with your points about fragility, though. If you can think of a way that handles both I'd be happy to hear it.
Regarding the above, I don't think trying to chase "someone might do something" at the expense of making regular package maintenance harder or knowingly break at least to some extent is a good approach.
Anyway, here's a couple of new thoughts:
First, daemons are usually restarted on upgrade after the old package has been removed, so if this is desirable and the trigger approach is used, the try-restart should be done in %triggerpostun instead of %triggerun, no?
Second, one way to ensure that the EVR of the package in the distro version that had the sysv scripts stays older than the one in which systemd migration happens even if the old distro version gets version updates is to bump Epoch when doing the migration, and take advantage of that in the versioned trigger.
Third, for my test case where the old package does its try-restart with "service" instead of invoking the init script directly, this appears to work fine:
%pre if [ $1 -gt 1 ] && [ ! -e %{_unitdir}/FOO.service ] && \ [ -e %{_initddir}/FOO ] ; then systemd-sysv-convert --save FOO &>/dev/null chkconfig --del FOO &>/dev/null || : fi
%post systemctl daemon-reload &>/dev/null || :
%preun if [ $1 -eq 0 ] ; then systemctl --no-reload disable FOO.service &>/dev/null systemctl stop FOO.service &>/dev/null || : fi
%postun systemctl daemon-reload &>/dev/null [ $1 -gt 0 ] && systemctl try-restart FOO.service &>/dev/null || :
I believe the conditions in %pre should prevent it from doing bad things (only when upgrading the package, and only if the sysv script is around but the unit file isn't yet). Note that daemon-reload is done in %post also for upgrades so that the "service FOO try-restart" in the old package's %postun will do the right thing. Note also no need for triggers in this scenario.
If the old package's %postun invokes the sysv init script directly, getting the daemon restarted gets uglier but using a temp file (for example %{_var}/run/%{name}-%{version}-%{release}-%{arch}.systemd-migration, referred to as %{migrfile} below), something like this works in my tests:
%pre rm -f %{migrfile} &>/dev/null if [ $1 -gt 1 ] && [ ! -e %{_unitdir}/FOO.service ] && \ [ -e %{_initddir}/FOO ] ; then systemd-sysv-convert --save FOO &>/dev/null chkconfig --del FOO &>/dev/null touch %{migrfile} &>/dev/null fi exit 0
%post [ $1 -eq 1 ] && systemctl daemon-reload &>/dev/null || :
%preun if [ $1 -eq 0 ] ; then systemctl --no-reload disable FOO.service &>/dev/null systemctl stop FOO.service &>/dev/null || : fi
%postun systemctl daemon-reload &>/dev/null [ $1 -gt 0 ] && systemctl try-restart FOO.service &>/dev/null || :
%triggerpostun -- %{name} if [ $1 -gt 0 ] && [ -e %{migrfile} ] ; then systemctl daemon-reload &>/dev/null systemctl try-restart FOO.service &>/dev/null fi rm -f %{migrfile} &>/dev/null || :
Side note -- I can't convince you to serve on the FPC again can I? I've been somewhat burnt out by the systemd guideline process and I have a conflict with the Board meetings so I've been thinking of leaving the FPC. But our crop of candidates whenever we've had to replace people has been pretty slim and we haven't managed to pick up anyone recently that carries list discussions back to FPC for consideration so I've been hesitant to do so. If you have time and inclination to step back into an FPC role let me know :-)
-Toshio
Sorry for sending private messages to the public list. I guess that'll teach me not to send email while attending two meetings :-)
-Toshio
On Tue, Jul 19, 2011 at 3:24 PM, Ville Skyttä ville.skytta@iki.fi wrote:
On 06/22/2011 07:24 PM, Toshio Kuratomi wrote:
We discussed this when we came up with the guidelines. IIRC, we finally decided this wasn't workable because we don't prevent people from packaging systemVinit scripts (either in subpackages or in a wholly separate package.
I agree with your points about fragility, though. If you can think of a way that handles both I'd be happy to hear it.
Regarding the above, I don't think trying to chase "someone might do something" at the expense of making regular package maintenance harder or knowingly break at least to some extent is a good approach.
I agree about breakage. But I guess we are drawing different lines regarding what's harder for regular package maintenance. One solution might be to have two separate scriptlets, one if you're retaining the sysv scripts and one if you aren't. OTOH, the systemd section is already pretty long and conditionalized which doesn't make for easy reading (perhaps it's inevitable when dealing with init; the SysV section was also pretty long and involved).
Anyway, here's a couple of new thoughts:
First, daemons are usually restarted on upgrade after the old package has been removed, so if this is desirable and the trigger approach is used, the try-restart should be done in %triggerpostun instead of %triggerun, no?
Is the important part that the old package has been removed or that the new package has been installed? If %triggerun is happening sufficiently late, then using it allows us to only have on trigger script rather than two. If it does make a difference, then you're right, we should move the try-restart portion to its own %triggerpostun.
Second, one way to ensure that the EVR of the package in the distro version that had the sysv scripts stays older than the one in which systemd migration happens even if the old distro version gets version updates is to bump Epoch when doing the migration, and take advantage of that in the versioned trigger.
I thought of this but didn't think that anyone would go for it. I think the argument against epoch has traditionally been that it's not user-visible and it's easy for packagers to forget to update dependencies when an epoch is in use.
Third, for my test case where the old package does its try-restart with "service" instead of invoking the init script directly, this appears to work fine:
%pre if [ $1 -gt 1 ] && [ ! -e %{_unitdir}/FOO.service ] && \ [ -e %{_initddir}/FOO ] ; then systemd-sysv-convert --save FOO &>/dev/null chkconfig --del FOO &>/dev/null || : fi
%post systemctl daemon-reload &>/dev/null || :
%preun if [ $1 -eq 0 ] ; then systemctl --no-reload disable FOO.service &>/dev/null systemctl stop FOO.service &>/dev/null || : fi
%postun systemctl daemon-reload &>/dev/null [ $1 -gt 0 ] && systemctl try-restart FOO.service &>/dev/null || :
I believe the conditions in %pre should prevent it from doing bad things (only when upgrading the package, and only if the sysv script is around but the unit file isn't yet). Note that daemon-reload is done in %post also for upgrades so that the "service FOO try-restart" in the old package's %postun will do the right thing. Note also no need for triggers in this scenario.
If the old package's %postun invokes the sysv init script directly, getting the daemon restarted gets uglier but using a temp file (for example %{_var}/run/%{name}-%{version}-%{release}-%{arch}.systemd-migration, referred to as %{migrfile} below), something like this works in my tests:
%pre rm -f %{migrfile} &>/dev/null if [ $1 -gt 1 ] && [ ! -e %{_unitdir}/FOO.service ] && \ [ -e %{_initddir}/FOO ] ; then systemd-sysv-convert --save FOO &>/dev/null chkconfig --del FOO &>/dev/null touch %{migrfile} &>/dev/null fi exit 0
%post [ $1 -eq 1 ] && systemctl daemon-reload &>/dev/null || :
%preun if [ $1 -eq 0 ] ; then systemctl --no-reload disable FOO.service &>/dev/null systemctl stop FOO.service &>/dev/null || : fi
%postun systemctl daemon-reload &>/dev/null [ $1 -gt 0 ] && systemctl try-restart FOO.service &>/dev/null || :
%triggerpostun -- %{name} if [ $1 -gt 0 ] && [ -e %{migrfile} ] ; then systemctl daemon-reload &>/dev/null systemctl try-restart FOO.service &>/dev/null fi rm -f %{migrfile} &>/dev/null || :
If you'd like to write this up as a draft I know that we beat ourselves up trying to remove the need for triggers before giving up. So we'd probably like to have something that does without them. Documenting how and what you've tested would also be good as testing these is one of the pain points when working on this. (For instance, this set of tests [which even after doing all that, still wasn't a complete set of tests] that I did prior to our discarding migration of boot-on/off status: https://fedoraproject.org/wiki/User:Toshio/Testing_systemd )
-Toshio
On 07/20/2011 08:10 PM, Toshio Kuratomi wrote:
On Tue, Jul 19, 2011 at 3:24 PM, Ville Skyttä ville.skytta@iki.fi wrote:
On 06/22/2011 07:24 PM, Toshio Kuratomi wrote:
First, daemons are usually restarted on upgrade after the old package has been removed, so if this is desirable and the trigger approach is used, the try-restart should be done in %triggerpostun instead of %triggerun, no?
Is the important part that the old package has been removed or that the new package has been installed? If %triggerun is happening sufficiently late, then using it allows us to only have on trigger script rather than two. If it does make a difference, then you're right, we should move the try-restart portion to its own %triggerpostun.
In my opinion it's quite clear: if it's desirable to restart daemons in %postun instead of %post, it should be done on %triggerpostun instead of %triggerun in this scenario as well.
The only thing where I think it matters is that if there's something in the old package that needs to be cleaned up before restarting the daemon on upgrades or else it will cause the new daemon to malfunction some way, the %*un ones should be used. For example files present in the old package but no longer present in the new one whose existence will cause the new daemon to not work as it should (note that at %post time files still present have already been overwritten by ones from the new package).
But regarding restarting the daemon in the case at hand: because sysv->systemd migrations are strictly limited to distro upgrade scenarios, I wouldn't personally mind it if the migrated services wouldn't restart at package upgrade time at all. This especially considering that running systemd-sysv-convert --apply foo is left for the user -- also telling users that migrated services might not restart before a reboot wouldn't be at all bad IMO. Not having to restart them would simplify scriptlets (and as noted earlier, if done properly, old packages using "service" in their %postun for restarting would work basically "for free" without further complication).
Documenting how and what you've tested would also be good as testing these is one of the pain points when working on this.
For now I've only thought about it more than a bit, and tested with various modified versions of the vdradmin-am package. I'll do some more tests this week and document and publish the results. Hopefully I'll manage to get enough done because starting from next week I won't have much time at all for that for a couple of weeks.
What I will _not_ be testing is setups using other init systems besides systemd. The current scriptlets in the Wiki don't attempt to take them into account either.
On 07/26/2011 08:41 PM, Ville Skyttä wrote:
For now I've only thought about it more than a bit, and tested with various modified versions of the vdradmin-am package. I'll do some more tests this week and document and publish the results. Hopefully I'll manage to get enough done because starting from next week I won't have much time at all for that for a couple of weeks.
Before starting more work on this, does this test set sound as one that has enough coverage, and are there any differing opinions on the expected outcomes? ("bootup state [not] saved" means whether it is written by systemd-sysv-convert in /var/lib/systemd/sysv-convert/database.)
1) pkg(sysv) -> pkg(systemd) upgrade
Expected outcome: sysv init script and symlinks removed, bootup state saved, service loaded from systemd unit, restarted if it was running.
2) pkg(systemd) -> pkg(systemd) upgrade, no sysv stuff present
Expected outcome: smooth usual package upgrade (no unusual errors), bootup state not saved, service loaded from systemd unit, restarted if it was running.
3) pkg(sysv) -> pkg(systemd) + pkg-sysv(sysv) upgrade
Expected outcome: sysv init script and possible symlinks installed, bootup state saved, service loaded from systemd unit, restarted if it was running.
4) pkg(sysv) + pkg-sysv(sysv) (init script co-ownership) -> pkg(systemd) upgrade
Expected outcome: pkg(systemd) and pkg-sysv(sysv) installed, sysv symlinks removed but init script in place, bootup state saved, service loaded from systemd unit, restarted if it was running.
5) pkg(systemd) -> pkg(systemd) upgrade while local non-packaged sysv init script installed
Expected outcome: all sysv stuff intact, bootup state not saved, service loaded from systemd unit, restarted if it was running.
6) pkg(systemd) initial install, no sysv stuff present
Expected outcome: bootup state not saved, service loaded from systemd unit, no errors.
7) pkg(systemd) initial install while local non-packaged sysv init script installed
Expected outcome: all sysv stuff intact, bootup state not saved, service loaded from systemd unit.
Not to be horribly glib, but...
Ville Skyttä (ville.skytta@iki.fi) said:
- pkg(sysv) -> pkg(systemd) + pkg-sysv(sysv) upgrade
Expected outcome: sysv init script and possible symlinks installed, bootup state saved, service loaded from systemd unit, restarted if it was running.
Don't do/support this.
- pkg(sysv) + pkg-sysv(sysv) (init script co-ownership) ->
pkg(systemd) upgrade
Expected outcome: pkg(systemd) and pkg-sysv(sysv) installed, sysv symlinks removed but init script in place, bootup state saved, service loaded from systemd unit, restarted if it was running.
REALLY don't do/support this.
- pkg(systemd) -> pkg(systemd) upgrade while local non-packaged sysv
init script installed
Expected outcome: all sysv stuff intact, bootup state not saved, service loaded from systemd unit, restarted if it was running.
This should behave the same, scriptwise, as option #2.
- pkg(systemd) initial install while local non-packaged sysv init
script installed
Expected outcome: all sysv stuff intact, bootup state not saved, service loaded from systemd unit.
This should behave the same, scriptwise, as #6.
Bill
On 07/26/2011 09:59 PM, Bill Nottingham wrote:
Ville Skyttä (ville.skytta@iki.fi) said:
- pkg(sysv) -> pkg(systemd) + pkg-sysv(sysv) upgrade
Expected outcome: sysv init script and possible symlinks installed, bootup state saved, service loaded from systemd unit, restarted if it was running.
Don't do/support this.
Packagers are already doing things this way, the packaging guidelines mandate this subpackaging approach if one wants to continue shipping the sysv scripts, and "yum install pkg pkg-sysv" will result in this scenario taking place on upgrade. So in my opinion either this scenario must be supported, or the sysv subpackage approach banned.
http://fedoraproject.org/wiki/Packaging:Systemd "If present, the SysV initscript(s) must go into an optional subpackage"
- pkg(sysv) + pkg-sysv(sysv) (init script co-ownership) ->
pkg(systemd) upgrade
Expected outcome: pkg(systemd) and pkg-sysv(sysv) installed, sysv symlinks removed but init script in place, bootup state saved, service loaded from systemd unit, restarted if it was running.
REALLY don't do/support this.
I dislike it as well, but on the other hand I believe my proposed scripts will work just fine in this scenario too - I'm basically just trying to come up with cases where sysv scripts might be around and cause problems. Why I'm doing that is a result from Toshio's earlier post in this thread in which he said "we don't prevent people from packaging systemVinit scripts ...". I have no problem dropping this test case though.
- pkg(systemd) -> pkg(systemd) upgrade while local non-packaged sysv
init script installed
Expected outcome: all sysv stuff intact, bootup state not saved, service loaded from systemd unit, restarted if it was running.
This should behave the same, scriptwise, as option #2.
Right, I listed it just for completeness (so that pkg(systemd)->pkg(systemd) upgrades don't touch possibly existing sysv stuff). No problem for me dropping this test case either.
- pkg(systemd) initial install while local non-packaged sysv init
script installed
Expected outcome: all sysv stuff intact, bootup state not saved, service loaded from systemd unit.
This should behave the same, scriptwise, as #6.
Yep, same thing as for the #5 vs #2 thing above.
Ville Skyttä (ville.skytta@iki.fi) said:
Expected outcome: sysv init script and possible symlinks installed, bootup state saved, service loaded from systemd unit, restarted if it was running.
Don't do/support this.
Packagers are already doing things this way, the packaging guidelines mandate this subpackaging approach if one wants to continue shipping the sysv scripts, and "yum install pkg pkg-sysv" will result in this scenario taking place on upgrade. So in my opinion either this scenario must be supported, or the sysv subpackage approach banned.
http://fedoraproject.org/wiki/Packaging:Systemd "If present, the SysV initscript(s) must go into an optional subpackage"
I'd prefer they be dropped entirely. Not everyone agrees with me, though.
Bill
On 07/26/2011 10:37 PM, Bill Nottingham wrote:
Ville Skyttä (ville.skytta@iki.fi) said:
http://fedoraproject.org/wiki/Packaging:Systemd "If present, the SysV initscript(s) must go into an optional subpackage"
I'd prefer they be dropped entirely. Not everyone agrees with me, though.
FWIW, I do.
On Tue, Jul 26, 2011 at 09:57:48PM +0300, Ville Skyttä wrote:
On 07/26/2011 08:41 PM, Ville Skyttä wrote:
For now I've only thought about it more than a bit, and tested with various modified versions of the vdradmin-am package. I'll do some more tests this week and document and publish the results. Hopefully I'll manage to get enough done because starting from next week I won't have much time at all for that for a couple of weeks.
Before starting more work on this, does this test set sound as one that has enough coverage, and are there any differing opinions on the expected outcomes? ("bootup state [not] saved" means whether it is written by systemd-sysv-convert in /var/lib/systemd/sysv-convert/database.)
- pkg(sysv) -> pkg(systemd) upgrade
Expected outcome: sysv init script and symlinks removed, bootup state saved, service loaded from systemd unit, restarted if it was running.
+1
- pkg(systemd) -> pkg(systemd) upgrade, no sysv stuff present
Expected outcome: smooth usual package upgrade (no unusual errors), bootup state not saved, service loaded from systemd unit, restarted if it was running.
+1
- pkg(sysv) -> pkg(systemd) + pkg-sysv(sysv) upgrade
Expected outcome: sysv init script and possible symlinks installed, bootup state saved, service loaded from systemd unit, restarted if it was running.
+1
This takes care of the default case of someone running Fedora with systemd. It's the same result as #1 but checking that the scriptlets are not negatively affected by the sysv init script package.
We do not need to test, for the purpose of these guidelines, whether the symlinks are installed and whether the non-default case of Fedora running a SysVinit works. Those would be things that people who want to run a sysvinit would need to work out and submit as a separate guideline for their packaging.
- pkg(sysv) + pkg-sysv(sysv) (init script co-ownership) ->
pkg(systemd) upgrade
Expected outcome: pkg(systemd) and pkg-sysv(sysv) installed, sysv symlinks removed but init script in place, bootup state saved, service loaded from systemd unit, restarted if it was running.
I'd like to say this shouldn't be supported but I can see how we'd get into this situation. admin has pkg(sysv). They install the *-sysv packages that they're interested in using. Upgrade to the pkg(systemd) package. The only thing I see that could be changed in the outcome would be: *ideally* I think that the sysv symlinks remain on the system but:
* I think that the current scriptlets don't do this * I think that FPC's discussion was that the upgrade from pkg(sysv) to pkg(systemd) was a step that would lead to suboptimal consequences no matter what we did in the end [1]_
So I think that sysv symlinks being removed wouldn't be a blocker here.
(Brainstorming whether we could prevent the pkg(sysv) and pkg-sysv(sysv) packages form being instaled together, I only see: * *(sysv) packages conflict with old versions of the package Conflicting gets us back into the but-I-want-to-rev-the-old-version issue that we have with the current triggers. * *(sysv) packages require the newer version of the package Requiring doesn't work well for the case of some sort of systemv-initscripts package that has initscripts for a bunch of popular services.
So I guess we can't avoid this scenario)
I'm more interested in the following, similar scenario:
4b) pkg(systemd) + pkg-sysv(sysv) installed -> pkg(systemd) upgrade
Expected outcome: pkg(systemd) and pkg-sysv(sysv) installed. sysv symlink untouched. bootup state probably not saved. service reloaded from systemd unit, restarted if running
This would be a common scenario for an admin that's running a sysvinit system under Fedora.
- pkg(systemd) -> pkg(systemd) upgrade while local non-packaged sysv
init script installed
Expected outcome: all sysv stuff intact, bootup state not saved, service loaded from systemd unit, restarted if it was running.
+1
Hopefully 4b) and this one would either both work or both fail.
- pkg(systemd) initial install, no sysv stuff present
Expected outcome: bootup state not saved, service loaded from systemd unit, no errors.
There's one caveat to this one which I'll explain right afterwards since it's actually a global concern.
- pkg(systemd) initial install while local non-packaged sysv init
script installed
Expected outcome: all sysv stuff intact, bootup state not saved, service loaded from systemd unit.
+1
So there's two global concerns. The one I hinted at earlier is that each of these tests needs to be run with the scriptlets for service-allowed-to-start-on-boot and scriptlets for service-not-allowed-to-start-on-boot. In upgrade cases of systemd=>systemd, the outcome should be the same. In upgrade cases of sysv=>systemd and initial install cases, the service should be enabled or disabled depending on whether the service is allowed to start on boot or not.
The other one is that we have to check both that the service was (loaded from the unit file/reloaded if running) and that it comes up appropriately (or does not come up appropriately) after a reboot.
(The combinations of these are what makes testing time consuming)
.. [1]_: Note that this is mostly tied to Lennart convincing us that we could not migrate boot-up-state appropriately. If migration of boot-up-state came back onto the table then we might have to reevaluate whether pkg(sysv) => pkg(systemd) could be smoothed in other areas. This is also the reason that we don't let people upgrade from sysv scripts to systemd scripts inside of a released Fedora and the prohibition would also be reevaluated if this were to change.
-Toshio
BTW, I just noticed what seems to me a rather surprising property of the currently recommended scriptlets for systemd migration: if the service is currently running when you upgrade from sysv to systemd-based package version, the service does get restarted, even though the boot start configuration for it is intentionally not migrated. Is this really desirable? It seems like a rather dangerous property, for a couple of reasons:
(1) systemd may not know how to stop the old service correctly. I observed exactly such a failure mode while testing mysqld, for instance --- it tried to start the new mysqld while the old was still running. This is no doubt related to this log message about the old service: Jul 26 20:08:01 rhl systemd[1]: mysqld.service: Supervising process 1790 which is not our child. We'll most likely not notice when it exits.
(2) starting the new service might lull the sysadmin into a false assumption that his boot-time start configuration for it is still there.
Now admittedly, it won't take being burned too many times for the average user to get over problem (2), but problem (1) remains.
regards, tom lane
On 07/27/2011 12:17 AM, Toshio Kuratomi wrote:
I'm more interested in the following, similar scenario:
4b) pkg(systemd) + pkg-sysv(sysv) installed -> pkg(systemd) upgrade
Expected outcome: pkg(systemd) and pkg-sysv(sysv) installed. sysv symlink untouched. bootup state probably not saved. service reloaded from systemd unit, restarted if running
This would be a common scenario for an admin that's running a sysvinit system under Fedora.
Good point. But on the other hand I can already say that it'll work, because the %pre I suggested will not do anything migration related if the systemd unit file is already in place...
(The combinations of these are what makes testing time consuming)
Does anyone have a quick-booting F-15 VM I could use for testing?
There's http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers but I'm not sure if this kind of stuff is appropriate there, how quickly will they reboot, or if the F-15 instance is in a state that is useful for testing (it says "f15 branched" which smells oldish). Kevin?
Does anyone have a quick-booting F-15 VM I could use for testing?
There's http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers but I'm not sure if this kind of stuff is appropriate there, how quickly will they reboot, or if the F-15 instance is in a state that is useful for testing (it says "f15 branched" which smells oldish). Kevin?
Sorry, I've corrected the page... that instance is a f15 final install.
You're welcome to use it for this... I'm not sure how fast they reboot either, but it shouldn't be all that long. ;)
If you run into problems just ping me and I can get the instance back up.
kevin
On 07/26/2011 08:41 PM, Ville Skyttä wrote:
I'll do some more tests this week and document and publish the results.
Ok, here's what I have so far:
http://scop.fedorapeople.org/systemd-migration/
In short, all tests done passed, and the 003 one was the only one that left a bit to be desired IMO. Test case descriptions and results are the *.txt files in that dir, packages/ contains the test packages used, and scriptlets/ contains instructions for two different cases of migrated packages.
Caveat: I have not tested the enabled/disabled state stuff at all yet, and it's almost certain that I won't have time to do much more than what's available now this or next week. After that it's possible that I'll have some time for this, but hopefully it won't be needed :)
On 06/03/2011 10:02 PM, Ville Skyttä wrote:
Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
Maybe I've missed some important thread or maybe I'm only a bit tired, but I don't get the following piece of snippet in http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd:
%triggerun -- httpd < 1.0-2 # Save the current service runlevel info # User must manually run systemd-sysv-convert --apply httpd # to migrate them to systemd targets /usr/bin/systemd-sysv-convert --save httpd >/dev/null 2>&1 ||:
Why can a user finish the migrating process *only manually*? Why "systemd-sysv-convert --apply httpd" cannot be run automatically after installation?
Honza
* English - detected * Czech * English * German
* Czech * English * German
On 06/03/2011 10:02 PM, Ville Skyttä wrote:
Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
I have another comment on the snippets. It seems to me like there is no daemon-reload when we're updating to systemd-enabled package the first time (i.e. we're removing init scripts and installing systemd unit files the first time -- daemon-reload is really needed after this operation).
I thinkg we should call daemon-reload in %triggerrun too, or am I missing something?
This is my proposed change:
%triggerun -- httpd < 1.0-2 +/bin/systemctl daemon-reload >/dev/null 2>&1 || : # Save the current service runlevel info # User must manually run systemd-sysv-convert --apply httpd # to migrate them to systemd targets /usr/bin/systemd-sysv-convert --save httpd >/dev/null 2>&1 ||:
Honza
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Honza Horak -
Kevin Fenzi -
Tom Lane -
Toshio Kuratomi -
Ville Skyttä