Description of problem: Note this has already been reported upstream [1] and my tests show that these does not affect two units of Type=simple Adding this to the blocker bug list since it might affect updates/upgrades since try-restart is run during %post in packages thus it breaks item 9 in the beta release requirements "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria " 1. https://bugs.freedesktop.org/show_bug.cgi?id=39824 Freeipa/389 Directory server guys are dependent on getting this fixed before they can convert to native systemd units.
Do you know how many packages are affected by this? I'm not clear on the impact of this beyond Freeipa/389ds.
Any unit that has been bound to another unit will hang on update
Discussed at 2011-09-02 blocker review meeting. All present agreed we need more concrete scenarios to accept this as a blocker: it's worrying in theory, but as we understand it, we need to identify whether there is actually any package in a default f15 install which would hit this issue on upgrade to f16. johann, lennart, can you check for any specific package that's likely to hit this? thanks!
This is not a question if this WILL break updates/upgrades on units of Type=forking ( and potentially some other types have not tested that ) that are bound to another unit regardless of that units type. This is a valid scenario and hit's the update/upgrade criteria with an easy reproducible scenario if you want to go through all the packages and potential private setup for end users that decided to bind their unit to another unit have at it I dont have the time to do it for you so go through all the unit files to "try" to find the one bound to another unit so you can then flag this as a blocker or just do it now.
(In reply to comment #4) > This is not a question if this WILL break updates/upgrades on units of > Type=forking ( and potentially some other types have not tested that ) that are > bound to another unit regardless of that units type. s/This is not a question if this WILL break/This WILL break/ ...
Oh I should mention that this affects BindTo and Requires if you are going to search for this...
Discussed at the 2011-09-09 blocker review meeting. We're still a bit worried about having no actual reproducers of this, but we agreed the potential impact on upgrades is significant enough to take it as a blocker. Lennart, can you please fix this soon? We need all acceptedblockers addressed by 09-14 in order to spin the RC.
I tested a yum upgrade from F15 (default DVD install) to F16 in a VM and didn't hit this bug, FWIW.
Again irrelevent this affects upgrades and updates
Passes simple telnet test and note there is still a (tight) window to have this in F16
Whoops wrong bug report
we really need some action on this; rc needs to be composed today or tomorrow, and all accepted blockers have to be addressed for that to happen.
Bill: Jared just suggested you might be of the opinion this bug does not need to be a blocker. If that's the case, could you add your rationale here? We can re-consider the bug's blocker status if you have new information which would contribute to our understanding of its effects.
Note: I'm checking my currently installed laptop. It is not the default install, but it may be close. If someone's got a default install, they can perform the same analysis. From /lib/systemd/system: $ grep BindTo * autovt@.service:BindTo=dev-%i.device fsck@.service:BindTo=%i.device getty@.service:BindTo=dev-%i.device serial-getty@.service:BindTo=dev-%i.device These are all bound to devices. We are not going to try-restart these services in an automated manner anyway. $ grep Requires *.service | grep "=.*.service" nfs-secure-server.service:Requires=var-lib-nfs-rpc_pipefs.mount nfs-server.service So, the only service I have that might trigger this is nfs-secure-service - it is not started by default, and therefore would not hit this unless I enabled it. (i.e., not beta criteria) I may be misunderstanding the trigger here, if so, I apologize.
notting: it's certainly plausible: none of the f15 -> f16 upgrade tests I've run have hit this issue. Johann is strongly of the opinion it should be considered a blocker even so, and so far we've deferred to him, but if you think it shouldn't be one as it's not likely to have a big practical impact on f15 -> f16 beta upgrades, that's certainly an important consideration. what are the chances that some post-beta F16 package update would start hitting this issue if we didn't fix systemd by beta, though?
It depends on the services that are configured. (I'm travelling and don't have good access to the full repo right now, otherwise it would be somewhat easier to check.)
I'm fine with changing this to -beta +nth +final granted that fesco will grant exception for service that are dependent on this being fixed so they can introduce their unit files ( freeipa guys depend on this working correctly if I can recall correctly there are few others as well).
we're already *frozen* for beta, so any service files that aren't in are going to need a fesco exception whether we delay the beta *release* for this bug or not.
Ok I was not sure when we actually hit that freeze since I thought they had been pushing out updates containing unit files today anyway we should atleast have this fixed before final.
OK, I'm re-voting -1 blocker as we have no demonstrated impact on any of the Beta criteria after TC testing. Any other votes?
I'm also re-voting -1 blocker since we haven't seen any issues with this thus far.
we have 3 votes for -1 blocker, so demoting to nth.
Fixed in git.
lennart: could we get an f16 build with just this specific fix, that we could pull into the Beta? Thanks.
systemd-36-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/systemd-36-2.fc16
Package systemd-36-2.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 systemd-36-2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/systemd-36-2.fc16 then log in and leave karma (feedback).
For F15 the fix is in https://admin.fedoraproject.org/updates/systemd-26-10.fc15
systemd-36-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.