---
# System prepended metadata

title: rpm-ostree and systemd-inhibitors

---

# rpm-ostree and systemd-inhibitors

 * [JL] UX of users using sd-inhibitors does not look great
 * [JL] I'd like to have the machine *not* block forever if there is an inhibitor stuck
 * [JL] this seems to come from a Zincati request, but haven't seen it outside of that
 * [CW] there aren't many other things doing auto-updates so far
 * [CW] OCP customers are segmenting nodes into different MachinePools to coordinate updates
 * [CW] I'd like to just have sd-inhibitors as a useful primitive, no matter what's the driver
 * [JL] let's draw an example: a custom updating every month; should they keep a month-long inhibitors
 * [CW] IMHO yes; also because MCO can now do reboot-less changes
 * [LB] in FCOS world, no need to keep the inhibitor for a month, you can have dedicated strategies for that
 * [JL] yes, it looks like a bit of race-y primitive, especially if there are multiple upgrades pending (i.e. barriers)
 * [LB] right now we are only considering rpm-ostree, but we can add logic at higher levels too (Zincati & MCO)
 * [CW] I'd like to have blocking inhibitors as a reliable primitive, not happy with rpm-ostree declaring an arbitrary timeout
 * [CW] MCO could be a bit smarter and mirror inhibitors/annotations to steer MCO away
 * [LB] we can layer stuff:
     * a timeout at the high-level (MCO / Zincati)
     * respecting blocks at the low-level by default (rpm-ostree)
     * a manual override to bypass blocks within rpm-ostree
 * [LB] last point possibly not worth, just rebooting the node will make any stuck block-inhibitor disappear
 * [JL] we should respect inhibitors at the OS level, without timeout or anything
 * [CW] rpm plugins knows how to use sd-inhibitors, we should make sure we are not deadlocking
 * [JL] we can experiment with the Zincati flow only, first
 * [LB] instead of starting to tackle this in rpm-ostree, we can do the some changed in MCO/Zincati to get an idea about real-world usage right now
 * [JL/CW] there are multiple update paths in MCO, and some of them do not require a drain+reboot
 * [KF] not sure which direction to go from here
 * [JL] a PR should be ok, if only Zincati goes through that codeflow
 * [CW] should rpm-ostree have a flag to ignore block-inhibitors?
 * [KF] my PR may likely interact with other consumers too
 * [KF] but it sounds like is ok to have rpm-ostree always respect block inhibitors
 * [KF] for later, whether we need a flag to ignore them
 * [JL] possibly not, it doesn't look very useful as a UX flow
 * [JL] for the Zincati flow, we still have no way for users to own the manual flow, but it would be good
 * [LB] ack, but I wouldn't mix into this discussion
 * [CW] MCO changes not a top priority right now, we can leave them for later