Bug 739279 - systemd service is enabled by default and on upgrade from pre-systemd package with no justification
Summary: systemd service is enabled by default and on upgrade from pre-systemd package...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: device-mapper-multipath
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Ben Marzinski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-17 07:41 UTC by Adam Williamson
Modified: 2011-10-11 03:15 UTC (History)
10 users (show)

Fixed In Version: device-mapper-multipath-0.4.9-19.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-11 03:15:39 UTC


Attachments (Terms of Use)

Description Adam Williamson 2011-09-17 07:41:43 UTC
Prior to the systemd conversion, the device-mapper-multipath service was not enabled by default. On my F15 system, the service is not enabled, and the init.d file does not specify any runlevels, indicating it is not enabled by default.

However, the systemd conversion put this section in %post:

if [ $1 -eq 1 ] ; then
	/bin/systemctl enable multipathd.service >/dev/null 2>&1 || :
fi

which will cause it to be enabled on new installs, and this triggerun:

%triggerun --  %{name} < 0.4.9-16
%{_bindir}/systemd-sysv-convert --save multipathd >/dev/null 2>&1 ||: 
bin/systemctl --no-reload enable multipathd.service >/dev/null 2>&1 ||:

which will cause it to be enabled on upgrade from the pre-systemd package.

There is no justification for changing the default state of the service given in the changelog, and services are supposed to require approval from FESCo to be enabled by default.

Viking, I'm starting to get worried that a lot of these sysv -> systemd conversions are setting services to be enabled by default and/or on upgrade that have no business to be. I would appreciate it if you'd go back and check through and make sure there are no more mistakes along these lines.

Comment 1 Jóhann B. Guðmundsson 2011-09-17 10:47:44 UTC
(In reply to comment #0)
> Prior to the systemd conversion, the device-mapper-multipath service was not
> enabled by default. On my F15 system, the service is not enabled, and the
> init.d file does not specify any runlevels, indicating it is not enabled by
> default.
> 
> However, the systemd conversion put this section in %post:
> 
> if [ $1 -eq 1 ] ; then
>  /bin/systemctl enable multipathd.service >/dev/null 2>&1 || :
> fi
> 
> which will cause it to be enabled on new installs, and this triggerun:
> 
> %triggerun --  %{name} < 0.4.9-16
> %{_bindir}/systemd-sysv-convert --save multipathd >/dev/null 2>&1 ||: 
> bin/systemctl --no-reload enable multipathd.service >/dev/null 2>&1 ||:
> 
> which will cause it to be enabled on upgrade from the pre-systemd package.
> 
> There is no justification for changing the default state of the service given
> in the changelog, and services are supposed to require approval from FESCo to
> be enabled by default.
> 
> Viking, I'm starting to get worried that a lot of these sysv -> systemd
> conversions are setting services to be enabled by default and/or on upgrade
> that have no business to be. I would appreciate it if you'd go back and check
> through and make sure there are no more mistakes along these lines.


You do realize that I'm not a proven packager so there absolutely nothing I can do about this and secondly this is the maintainers headache or whom every package the component in the first place. 

The only reason I started to provide spec files was because Toshio asked me to and there might be a whole bunch of other errors in those spec files if people just blindly used them.

Comment 2 Milan Broz 2011-09-17 14:19:25 UTC
Obviously such switch will cause many such problems, that's normal.

IIRC after update it should be "fresh" installation. For multipathd it is not so simple, anaconda allows installation on multipath device and the start it by default makes perfect sense for such config.Obviously such change

I explicitly asked (for mdadm) if upgrade should take into account that use disabled service and response was the no, it should switch to default state.
So upgrade to systemd perhaps just switched service to default state. IMHO only anaconda know for the fresh install if multipath service should be started by default...

Is there some guidelines for such situations? (I think that conversion here was correct.)

Comment 3 Milan Broz 2011-09-17 14:21:43 UTC
(Sorry seems I mixed up the text in edit box for previous comment. I hope it still readable though :-)

Comment 4 Adam Williamson 2011-09-17 17:21:28 UTC
I've been referring to https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Systemd

I can certainly see the problem - we need configurations where multipathd was enabled before to still have it enabled now. The problem is that comps has this:

<group>
    <id>base</id>
    <_name>Base</_name>
...
<packagereq type="default">device-mapper-multipath</packagereq>

So just about everyone has device-mapper-multipath installed by default and hence, now, enabled by default.

If the only options are 'blind enable on upgrade' or 'blind disable on upgrade' I can see the argument for the former being the least worst option for the upgrade case; we don't want people's systems to stop booting. But I'd think you could still take out the %post snippet. How was it set to 'enabled' (when necessary) before? Did anaconda do it? If so, we can check that bit of anaconda logic has been updated to systemd, and if so, there's no need to enable it by default in the package %post.

I think the best answer might be to improve the range of options. There is this bit in the snippets:

%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 ||:

so systemd does actually have a helper which allows you to 'migrate' service configuration. It seems like there should be a way we can utilize that, on upgrade, to ensure people get the same configuration after as they had before - at least when upgrading via anaconda, maybe.

I think I'm going to raise this one with FESCo.

Comment 5 Milan Broz 2011-09-19 10:17:13 UTC
Thanks
https://fedorahosted.org/fesco/ticket/670

Comment 6 Milan Broz 2011-09-19 10:29:45 UTC
Ben, I think you should add 
ConditionPathExists=/etc/multipath.conf

to systemd unit file. So if there is no config, service is not started, This should help in most situations IMHO.

Comment 7 Adam Williamson 2011-09-19 15:18:48 UTC
I was gonna suggest something along those lines too. systemd does have some neat capabilities.

Comment 8 Ben Marzinski 2011-09-22 00:30:53 UTC
I've added

ConditionPathExists=/etc/multipath.conf

to the systemd service files.

Comment 9 Fedora Update System 2011-09-22 02:54:41 UTC
device-mapper-multipath-0.4.9-19.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/device-mapper-multipath-0.4.9-19.fc16

Comment 10 Fedora Update System 2011-09-24 20:48:16 UTC
Package device-mapper-multipath-0.4.9-19.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing device-mapper-multipath-0.4.9-19.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/device-mapper-multipath-0.4.9-19.fc16
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2011-10-11 03:15:39 UTC
device-mapper-multipath-0.4.9-19.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.