Bug 735013 - FIXED_IN_GIT: Having unit B bound or required to unit A and restarting unit A while it's active results hang
FIXED_IN_GIT: Having unit B bound or required to unit A and restarting unit A...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
AcceptedNTH RejectedBlocker
:
Depends On:
Blocks: 695736 F16Beta-accepted/F16BetaFreezeExcept
  Show dependency treegraph
 
Reported: 2011-09-01 03:40 EDT by Jóhann B. Guðmundsson
Modified: 2011-09-30 14:53 EDT (History)
11 users (show)

See Also:
Fixed In Version: systemd-36-3.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-09-30 14:53:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jóhann B. Guðmundsson 2011-09-01 03:40:03 EDT
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.
Comment 1 Tim Flink 2011-09-02 12:06:14 EDT
Do you know how many packages are affected by this? I'm not clear on the impact of this beyond Freeipa/389ds.
Comment 2 Jóhann B. Guðmundsson 2011-09-02 12:12:17 EDT
Any unit that has been bound to another unit will hang on update
Comment 3 Adam Williamson 2011-09-02 14:38:11 EDT
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!
Comment 4 Jóhann B. Guðmundsson 2011-09-05 05:23:54 EDT
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.
Comment 5 Jóhann B. Guðmundsson 2011-09-05 05:25:23 EDT
(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/ ...
Comment 6 Jóhann B. Guðmundsson 2011-09-05 06:35:54 EDT
Oh I should mention that this affects BindTo and Requires if you are going to search for this...
Comment 7 Adam Williamson 2011-09-09 14:05:11 EDT
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.
Comment 8 Adam Williamson 2011-09-09 19:02:14 EDT
I tested a yum upgrade from F15 (default DVD install) to F16 in a VM and didn't hit this bug, FWIW.
Comment 9 Jóhann B. Guðmundsson 2011-09-09 19:15:34 EDT
Again irrelevent this affects upgrades and updates
Comment 10 Jóhann B. Guðmundsson 2011-09-09 19:21:18 EDT
Passes simple telnet test and note there is still a (tight) window to have this
in F16
Comment 11 Jóhann B. Guðmundsson 2011-09-09 19:21:46 EDT
Whoops wrong bug report
Comment 12 Adam Williamson 2011-09-13 14:16:49 EDT
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.
Comment 13 Adam Williamson 2011-09-14 14:53:44 EDT
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.
Comment 14 Bill Nottingham 2011-09-14 18:07:09 EDT
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.
Comment 15 Adam Williamson 2011-09-14 18:22:16 EDT
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?
Comment 16 Bill Nottingham 2011-09-14 18:32:07 EDT
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.)
Comment 17 Jóhann B. Guðmundsson 2011-09-14 18:40:54 EDT
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).
Comment 18 Adam Williamson 2011-09-14 18:55:51 EDT
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.
Comment 19 Jóhann B. Guðmundsson 2011-09-14 19:17:53 EDT
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.
Comment 20 Adam Williamson 2011-09-15 00:38:48 EDT
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?
Comment 21 Tim Flink 2011-09-15 00:46:13 EDT
I'm also re-voting -1 blocker since we haven't seen any issues with this thus far.
Comment 22 Adam Williamson 2011-09-15 03:06:42 EDT
we have 3 votes for -1 blocker, so demoting to nth.
Comment 23 Lennart Poettering 2011-09-21 13:58:03 EDT
Fixed in git.
Comment 24 Adam Williamson 2011-09-21 21:01:53 EDT
lennart: could we get an f16 build with just this specific fix, that we could pull into the Beta? Thanks.
Comment 25 Fedora Update System 2011-09-23 13:05:55 EDT
systemd-36-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/systemd-36-2.fc16
Comment 26 Fedora Update System 2011-09-24 16:48:40 EDT
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).
Comment 27 Michal Schmidt 2011-09-25 19:33:13 EDT
For F15 the fix is in https://admin.fedoraproject.org/updates/systemd-26-10.fc15
Comment 28 Fedora Update System 2011-09-30 14:52:16 EDT
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.

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