Join GitHub today
systemd fails to parse mount unit drop-in configs when the unit was detected as not-found previously #8587
systemd version the issue has been seen with
systemd-237 (per this comment) and systemd-234-10.git5f8984e.fc27.x86_64
This bug report is a port of the issue originally reported on the Red Hat Bugzilla as #1560234 as it has been confirmed to still occur with upstream system.
Under very specific conditions, I've noticed that systemd will fail to parse drop-in configs at all - it looks like an ordering issue with the build-in mount unit generator. Those conditions are:
In case of bug report: Expected behaviour you didn't see
Drop-in configs are parsed, and foo.service is started. This can be realized by omitting step 2.
In case of bug report: Unexpected behaviour you saw
Drop-in configs are not parsed missing and systemd does not report cgroup.
Note how this mount unit (1) has not parsed the drop-ins, requesting daemon reload (2) is not based on /proc/self/mountinfo (3) has no cgroup.
In case of bug report: Steps to reproduce the problem
Context for this issue is that I have encrypted filesystems that are loaded manually post-boot. Some service depend on these mounts, so I want the services to be started automatically once they do eventually get mounted (via a
This works but the service still happily starts without the mounted fs -- so I have also add a
referenced this issue
Mar 27, 2018
This issue is caused by a misunderstanding:
Thus, if you want to use /etc/systemd/system/mnt-tmp.mount.d/start-foo.conf, then mnt-tmp.mount file must exist somewhere. AFAICT, there is not bug.
There's a minor buglet: it seems pointless to load drop-ins for mount points created from /proc/self/mountinfo, since by the time they are read, the mount point is already active. But it seems like a very edge case, so I wouldn't spend energy on fixing this unless somebody shows that this matters somehow.
Hi Zbigniew ,
I don't disagree here -- the
Here is where I respectfully disagree, as I have the intended behavior working with drop-ins for mount points created from /proc/self/mountinfo: when those mount points are created on-the-fly, the drop-ins are read which pulls in eg.
Regardless, I would expect that even if this is decided as something to be unsupported that systemd's dependency solving or config loading behavior for mount units would not vary when depending on if a depending service is enabled/disabled.
It does not "vary on whether it is enabled/disabled", it varies based upon when and how the service is loaded. When it is loaded determines how it is loaded. When it is loaded before mounting, it fails to load, like described above. When it is loaded after mounting, i.e. synthetized from /proc/self/mountinfo, it "loads" successfully.
We could make this "consistent" by disallowing mounts to be created from /proc/self/mountinfo, i.e. by forbidding mount calls that do not go through systemd. I don't think anybody would like that. OTOH, normal mount units require What= to be specified, so it's reasonable to require the main file to be present. (We could allow just drop-ins without the main file, assuming that What= would be specified somewhere, but that would be even more confusing and wouldn't really change anything.)
You're using some corner-cases of the implementation. In particular Before= cannot be realized — after all, once the mount is detected, it is already too late. Hence, I think it'd be more robust and predictable to use normal .mount units for this, and allow systemd to resolve the dependencies.
I am not sure I understand what transaction you mean here. There is no reboot; there is only
@filbranden thanks for the suggestion -- I have looked at that, although it would work it would also require I create (and maintain) copies of mount units for every filesystem I create. Auto-generated mount units with drop-in configs maintains the ideal behavior, allowing for starting start of services when the mount happens, whenever that may be.
Because these are non-root encrypted filesystems for which I want to manually enter the key (but not block boot on), the scheduling aspect of systemd-mount also provides me with little benefit compared to autogenerated mounts.
@keszybz I suppose what I am saying is that as a user, it seems bizarre that a failure to load a non-existent unit would affect the behavior of a unit by the same name should it be actually generated in the future, as we see here for these
Instead of disabling all
Yeah, "transaction" wasn't the right word. I was thinking of behaviour that would be observed after a reboot, which would exhibit the same effect as the reproducer shown above.
OK, that is a good point. We should load drop-ins when generating a mount based on