Xapi service depends on systemd-tmpfiles-setup

[gthvn1]

👋
To give a little bit of context, I had a strange issue after building new RPMs (it was a new version of ZFS) and installing it. It appeared that systemd reported XAPI has failed. I looked more closely and the reason is because /var/lock/subsys directory is not present anymore (and the touch /var/lock/subsys/xapi command failed). I didn't know exactly why this directory is not there but after discussing with several people it appears that it should be created by systemd-tmpfiles-setup.service. And in my case this service didn't start. To fix the issue one suggestion was to add systemd-tmpfiles-setup.service to be Requires+After in xapi.service. I think it makes sense and that is is the right way for fixing the issue but I was surprised that it wasn't already the case, so maybe there is another way to fix this?
Regards,

[edwintorok]

That directory is indeed created by /usr/lib/tmpfiles.d/legacy.conf. We probably don't need the subsystem locking anymore with systemd (and those scripts that need it could mkdir -p it themselves).
Until all the scripts are updated this seems like the correct change.

[bernhardkaindl]

• Sometimes, Codecov sometimes gets confused when the PR is not rebased to the latest target branch

If you rebase to today's latest master branch with the Codecov config updates, it should pass in case (also makes Codecov more tolerant for test coverage)

[lindig]

Any reason not to merge this?

[psafont]

We want to cut a new release with the vtpm changes ASAP, with as little risk as possible. We can merge this after we've cut a new release, along with other held-off PRs, like #5451