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.
(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.
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.)
(Sorry seems I mixed up the text in edit box for previous comment. I hope it still readable though :-)
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.
Thanks https://fedorahosted.org/fesco/ticket/670
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.
I was gonna suggest something along those lines too. systemd does have some neat capabilities.
I've added ConditionPathExists=/etc/multipath.conf to the systemd service files.
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
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).
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.