3:02 p.m.
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.
1:29 p.m.
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.
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.
11:24 a.m.
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
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
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.
2) 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.
3) 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
5:37 a.m.
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
>
> 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
>
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.
> 3) 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?
7:40 p.m.
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
>>
>> 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
>>
> 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.
>> 3) 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
5:24 p.m.
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 || :
10:03 a.m.
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
11:24 a.m.
Sorry for sending private messages to the public list. I guess
that'll teach me not to send email while attending two meetings :-)
-Toshio
12:10 p.m.
On Tue, Jul 19, 2011 at 3:24 PM, Ville Skyttä <ville.skytta(a)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
12:41 p.m.
On 07/20/2011 08:10 PM, Toshio Kuratomi wrote:
On Tue, Jul 19, 2011 at 3:24 PM, Ville Skyttä
<ville.skytta(a)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.
1:57 p.m.
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.
1:59 p.m.
Not to be horribly glib, but...
Ville Skyttä (ville.skytta(a)iki.fi) said:
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.
Don't do/support this.
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.
REALLY don't do/support this.
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.
This should behave the same, scriptwise, as option #2.
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.
This should behave the same, scriptwise, as #6.
Bill
2:31 p.m.
On 07/26/2011 09:59 PM, Bill Nottingham wrote:
Ville Skyttä (ville.skytta(a)iki.fi) said:
> 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.
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"
> 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.
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.
> 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.
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.
> 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.
This should behave the same, scriptwise, as #6.
Yep, same thing as for the #5 vs #2 thing above.
2:37 p.m.
Ville Skyttä (ville.skytta(a)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
2:46 p.m.
On 07/26/2011 10:37 PM, Bill Nottingham wrote:
Ville Skyttä (ville.skytta(a)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.
4:17 p.m.
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.)
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.
+1
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.
+1
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.
+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.
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.
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.
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.
+1
Hopefully 4b) and this one would either both work or both fail.
6) 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.
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.
+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
7:26 p.m.
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
12:54 a.m.
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?
11:54 a.m.
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
5:26 p.m.
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 :)
12:34 p.m.
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
<javascript:void(0);> <#>
10:35 a.m.
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
4636
days inactive
4703
days old
packaging@lists.fedoraproject.org
22 comments
6 participants
participants (6)
-
Bill Nottingham -
Honza Horak -
Kevin Fenzi -
Tom Lane -
Toshio Kuratomi -
Ville Skyttä