stratisd.service: After=multi-user.target creates ordering cycle for dependent services

[kriansa]

Hello all! First of all, thanks for the great work on Stratis. I just recently started using it, and it's amazing.

I have a Podman volume plugin backed by Stratis. It works well for containers created after the host has initialized, but for containers using Quadlet (which are essentially systemd units), I have a dependency ordering issue that prevents units with stratis volumes from initializing at boot.

I took some time to analyze the current unit file and test a potential fix for any service that depends on stratisd.service.

Context

For context, stratisd.service currently uses:

DefaultDependencies=no
After=multi-user.target
...
[Install]
WantedBy=multi-user.target

This creates an ordering cycle for any service in multi-user.target that depends on stratisd. For example, my volume plugin service has:

After=stratisd.service
Wants=stratisd.service

[Install]
WantedBy=multi-user.target

Produces the cycle:

podman-volume-stratis.service -> (After) -> stratisd.service -> (After) -> multi-user.target -> podman-volume-stratis.service

The After=multi-user.target was introduced in #3826 (changing from After=local-fs.target) as part of reworking fstab/Clevis dependencies. Since early boot device assembly is now handled by stratisd-min-postinitrd, the full stratisd daemon doesn't need special boot ordering — it just needs D-Bus, which is available after basic.target.

Proposed fix

I would remove DefaultDependencies=no and After=multi-user.target from stratisd.service.in. The standard default dependencies already provide After=sysinit.target basic.target, which ensures D-Bus availability for the Type=dbus service. This allows downstream services to use After=stratisd.service without creating cycles. I've tested this locally, and it's working -- at least for my use cases.

I'm willing to submit a PR if you agree with the fix.

[coderabbitai]

🔗 Related PRs

#3908 - Follow the recommended dracut module ordering for out-of-tree modules. [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[jbaublitz]

Hi @kriansa thanks for the detailed description of the problem. Let me refresh my memory on why we made this change and get back to you. Unfortunately it seems like something breaks every time we touch dependency ordering so I need to make sure that we cover all currently known cases in testing.

[jbaublitz]

Hi @kriansa thank you for your patience as I page everything back into memory. I wanted to refer you to this document. https://www.freedesktop.org/software/systemd/man/latest/bootup.html?__goaway_challenge=meta-refresh&__goaway_id=6101d8b19a9d5a32c140a58248c3e7a8&__goaway_referer=https%3A%2F%2Fwww.google.com%2F The reason we chose the multi-user target is specifically because multi-user is the first parent of both local and remote filesystem targets. There may be a better way to satisfy both your requirements and our requirements, but as I recall, when we did not implement this restriction, we bumped into problems with Clevis and remote filesystems when we tried to set them up in fstab. If you have a solution that can also work in the Clevis case for fstab, I'm happy to take a look and test.

[kriansa]

HI @jbaublitz ! I appreciate your patience and time in reviewing this issue.

I get that multi-user.target is the convergence point for both local-fs.target and remote-fs.target. I also understand the caution around Clevis — the rework in #3826 addressed actual breakage, and I don't want to reintroduce it. I went back through that PR to make sure the proposed fix is safe.

The good news is that the fstab boot path is handled entirely by stratisd-min-postinitrd and the stratis-fstab-setup units, which are independent of stratisd.service.

PR #3826 made three changes:

1. Added stratis-fstab-setup-with-network@.service — a new unit for network-dependent fstab entries (After=network-online.target, Before=remote-fs-pre.target, Requires=stratisd-min-postinitrd.service)
2. Removed Before=local-fs-pre.target from stratisd-min-postinitrd.service — decoupled the early-boot daemon from local filesystem ordering
3. Changed stratisd.service from After=local-fs.target to After=multi-user.target

The Clevis fix is entirely in changes 1 and 2 — they route fstab setup through stratisd-min-postinitrd (a Type=notify service using JSON-RPC over Unix socket), which is completely independent of the full stratisd daemon (which uses D-Bus and needs to be After=basic.target). Change 3 pushed the D-Bus daemon later in boot, but has no role in fstab assembly.

I built a QEMU-based reproduction that demonstrates this concretely: https://github.com/kriansa/stratisd-boot-cycle-repro

It boots a Fedora 43 VM with stratisd installed and verifies:

1. The ordering cycle exists with the current unit file (so my downstream service can't depend on stratisd)
2. Removing DefaultDependencies=no and After=multi-user.target resolves the cycle
3. A simulated Clevis/network fstab service (mirroring stratis-fstab-setup-with-network@ ordering) completes successfully — unaffected by the change
4. A downstream service depending on stratisd starts correctly after the fix

Let me know if it makes sense to you. I'm happy to submit a PR to remove the two lines if this looks good to you.

[jbaublitz]

@kriansa Thanks so much for looking into this so deeply, the help testing is much appreciated! I believe @mulkieran will want us to test just to make sure, but I think on our end this is likely a beneficial change and if you put up the PR, I'm happy to test and review the change in a few different environments we support.