Description of problem: After a transition from a working openssh-5.8p1-27.fc16.1 to openssh-5.8p1-30.fc16.1 status for sshd service shows: sshd.service - OpenSSH server daemon. Loaded: loaded (/lib/systemd/system/sshd.service) Active: inactive (dead) CGroup: name=systemd:/system/sshd.service That despite that "chkconfig sshd --list" reports .... 3:on 4:on 5:on .... To ensure that sshd really starts on boot one has to add in /etc/systemd/system/multi-user.target.wants a mising link sshd.service to /lib/systemd/system/sshd.service. If that would be a truly remote machine such "upgrade" would create a serious problem (and quite costly in a number of scenarios). Version-Release number of selected component (if applicable): openssh-5.8p1-30.fc16 How reproducible: always
This caused a serious problem for me. I know if you look at daemon(7) it describes the right way to handle updates in the spec files. I'm not sure how to fix it now that it's broken. But hopefully you can quickly stop breaking people's working systems....
(In reply to comment #1) > I'm not sure how > to fix it now that it's broken. But hopefully you can quickly stop breaking > people's working systems.... Something like that in %post of openssd-server package? if chkconfig sshd --list | grep -q 3:on ; then if [ ! -L /etc/systemd/system/multi-user.target.wants/sshd.service ]; then ... do whatever magic required to unbreak the system ... fi fi Likely "magic" is something with 'systemctl enable ...' or just make that link. Also instead of checking directly for that link one can probably do: if ! systemctl list-units | grep -q sshd ; then ..... fi
the scriptlets are now according to the systemd-packaging-guide
They are still wrong. This will break every user who updates. They will loose ssh access to their box. Which guidelines did you look at? I will make sure they get fixed to indicate that you need something like (from man (7) daemon): %triggerun -- foobar < 0.47.11-1 if /sbin/chkconfig --level 3 foobar ; then /bin/systemctl --no-reload enable foobar.service foobar.socket >/dev/null 2>&1 || : fi This is what enables the service on an update IFF it was enabled in runlevel 3 before the update. I'm not sure how that's going to work along with your chkconfig --add on every update, so it might take some testing.....
(In reply to comment #4) > > %triggerun -- foobar < 0.47.11-1 Maybe I am misinformed but I heard that package triggers are frowned upon. OTOH checking that /sbin/chkconfig is aware of sshd but 'systemctl list-units' is not, and acting on that information in a %post script, does not look to me that complicated. That does not need any specific version information.
(In reply to comment #4) > > %triggerun -- foobar < 0.47.11-1 > if /sbin/chkconfig --level 3 foobar ; then > /bin/systemctl --no-reload enable foobar.service > foobar.socket >/dev/null 2>&1 || : > fi > this switch the service on every time when the package is updated and originaly was in runlevel 3. IMHO it's wrong.
You need to set the version there equal to the last version using sysinit. This will only be run the first time one updates past the version that removes sshd from sysinit. After you update to systemd you should remove it from chkconfig with --del. I believe both the NM and the sssd packages have sucessfully implemented spec files that handle updates. As it stands today every F16 box that you update will lose ssh on the next reboot. That's a huge problem and why this method was documented....
(In reply to comment #7) > > After you update to systemd you should remove it from chkconfig with --del. > This is a problem because deleting the ssh from sysv-init is problem for those who uses it instead of systemd.
I thought we were trying to move away from sysv-init and to just use systemd. It's not possible or supported to install F16 without systemd. I understand that upstream might not want to completely drop chkconfig, but in F16 we should. In any case post seems wrong, since you are going to add it into chkconfig every time, not just on initial install. (which explains why my box now has it enabled in chkconfig and in systemd) I'd pretty strongly suggest putting the if [-x server] as an 'else' clause to systemd if you need support for both. I'm guessing that postun is going to double restart it based on how it is coded there.... preun might be right.... I still think you should just convert all the way to systemd and use the trigger like in the man page....
Jan, non-systemd systems are not supported anymore on Fedora, no need for that compatibility. Also, it is not strictly necessary to remove the old sysv services, as they are ignored when native services exist by the same name.
Temporarily revert sytemd units according to https://bugzilla.redhat.com/show_bug.cgi?id=697698#c30 There is still nor fpc nor fesco guidance how to do it.