-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ostree-remount.service: RemainAfterExit=yes #1697
Conversation
This is standard practice for units like this; e.g. it's what `systemd-remount-fs.service` does. I think it may be part of or the whole cause for coreos/rpm-ostree#1471 I haven't reproduced the problem exactly but it seems to me that if the unit starts and is GC'd, then when systemd goes to execute a later unit it might end up restarting it. A noticeable side effect of this is that `systemctl status ostree-remount` exits with code `0` as expected.
this is something I should be able to test on my failing system, right? would I need to make the change and then enable initrfamfs generation in order to get the change to propagate into the initrfd? |
Don't need to do that, this runs in the main system. You can just
|
Good catch! This makes sense to me regardless of its (likely) role in coreos/rpm-ostree#1471. (Though cross-posting here too: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750683 indicates that oneshot services that are depended upon can indeed get executed multiple times if without |
☀️ Test successful - status-atomicjenkins |
👍 This seems to have resolved the problem for me. If I add |
See ostreedev/ostree#1697 Just noticed this while investigating our services after the recent machine-id regression.
See ostreedev/ostree#1697 Just noticed this while investigating our services after the recent machine-id regression.
For the same reasons as ostreedev#1697. This is especially important in services that are likely to be used as an `After/Before=` target in other units. `ostree-prepare-root.service` is one such service.
This is important for `Type=oneshot` services that may be depended upon by other services. See ostreedev/ostree#1697.
Omitting this can cause the unit to be executed multiple times if it's a dependency of another unit (as these are). See ostreedev/ostree#1697 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750683
Noticed this while looking at the unit file for a different RHEL CoreOS issue. See ostreedev/ostree#1697 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750683 Omitting this can cause the service to run multiple times if something else ends up depending on it, which I'm guessing we don't want. Signed-off-by: Colin Walters <walters@verbum.org>
Noticed this while looking at the unit file for a different RHEL CoreOS issue. See ostreedev/ostree#1697 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750683 Omitting this can cause the service to run multiple times if something else ends up depending on it, which I'm guessing we don't want. Closes: #72 Signed-off-by: Colin Walters <walters@verbum.org> Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This is standard practice for units like this; e.g. it's what
systemd-remount-fs.service
does. I think it may be part ofor the whole cause for
coreos/rpm-ostree#1471
I haven't reproduced the problem exactly but it seems to me that
if the unit starts and is GC'd, then when systemd goes to execute
a later unit it might end up restarting it.
A noticeable side effect of this is that
systemctl status ostree-remount
exits with code
0
as expected.