boot: Add ostree-finalize-staged.path #1740
Conversation
| Documentation=man:ostree(1) | ||
|
|
||
| [Path] | ||
| PathExists=/run/ostree/staged-deployment |
There was a problem hiding this comment.
When is this condition evaluated though? Is it only once at startup?
There was a problem hiding this comment.
It's monitored using inotify: https://www.freedesktop.org/software/systemd/man/systemd.path.html
It'd be nice if this also deactivated the service if we did e.g. rpm-ostree cleanup -p, but alas: systemd/systemd#3642
Though at least we'd gain that for free once/if that gets implemented.
Right. So we can do that now and then land this after the next release? |
In preparations for ostreedev/ostree#1740, just hard enable this path unit for now since centrally-maintained distro presets still need to be updated.
Rather than manually starting the `ostree-finalize-staged.service` unit, we can leverage systemd's path units for this. It fits quite nicely too, given that we already have a path we drop iif we have a staged deployment. To give some time for the preset to make it to systems, we don't yet drop the explicit call to `systemctl start`. Though we do make it conditional based on a DEBUG env var so that we can actually test it in CI for now. Once we're sure this has propagated, we can drop the `systemctl start` path and the env var together.
|
OK, I've tested this in combination with coreos/rpm-ostree#1617. As the commit message mentions, I think we can get this in now for the upcoming release and then in the next release or the one after, drop that |
Right, this'll be fixed by the dist-git PR, though |
In preparations for ostreedev/ostree#1740, just hard enable this path unit for now since centrally-maintained distro presets still need to be updated. Closes: #1617 Approved by: cgwalters
|
bot, retest this please |
|
@rh-atomic-bot r+ cdda3a0 |
|
🙀 |
|
📌 Commit e092139 has been approved by |
Rather than manually starting the `ostree-finalize-staged.service` unit, we can leverage systemd's path units for this. It fits quite nicely too, given that we already have a path we drop iif we have a staged deployment. To give some time for the preset to make it to systems, we don't yet drop the explicit call to `systemctl start`. Though we do make it conditional based on a DEBUG env var so that we can actually test it in CI for now. Once we're sure this has propagated, we can drop the `systemctl start` path and the env var together. Closes: #1740 Approved by: cgwalters
|
@rh-atomic-bot retry |
|
☀️ Test successful - status-atomicjenkins |
Doing this before the upstream PR[1] gets merged because upstream CI needs to be able to build RPMs, which uses this. Anyway, the glob is kept general so it's equally valid even without path. [1] ostreedev/ostree#1740
Rather than manually starting the
ostree-finalize-staged.serviceunit,we can leverage systemd's path units for this. It fits quite nicely too,
given that we already have a path we drop iif we have a staged
deployment.
I started on this thinking we somehow didn't have to change presets. But of course, we do still need a preset for the path unit itself. So anyway, just throwing this up here, since I do think overall that using a path unit is nicer, but this is now predicated on getting a preset added in distros (at least for rpm-ostree-based downstreams, we can just do like in #1482, for others... we'd need to mention it clearly in the release notes).