summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorColin Walters <walters@verbum.org>2018-07-31 17:04:26 -0400
committerAtomic Bot <atomic-devel@projectatomic.io>2018-07-31 21:15:57 +0000
commitdcd1522969a36eb4bed7a001154342355d0539ef (patch)
tree6c223c0d63465f71b23843c56d4a2012e37934a5
parent61c37aa40cb19b0bb631bf5498ee517b020e1759 (diff)
downloadostree-dcd1522969a36eb4bed7a001154342355d0539ef.tar.gz
ostree-remount.service: RemainAfterExit=yes
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 https://github.com/projectatomic/rpm-ostree/issues/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. Closes: #1697 Approved by: jlebon
-rw-r--r--src/boot/ostree-remount.service1
1 files changed, 1 insertions, 0 deletions
diff --git a/src/boot/ostree-remount.service b/src/boot/ostree-remount.service
index 68209f96..47e1387a 100644
--- a/src/boot/ostree-remount.service
+++ b/src/boot/ostree-remount.service
@@ -31,6 +31,7 @@ Before=systemd-tmpfiles-setup.service
[Service]
Type=oneshot
+RemainAfterExit=yes
ExecStart=/usr/lib/ostree/ostree-remount
StandardInput=null
StandardOutput=syslog