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.servicedoes. 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-remountexits with code
0as expected.