core/mount: stop generating mount units for cred mounts
authorMike Yuan <me@yhndnzj.com>
Tue, 14 May 2024 10:33:32 +0000 (18:33 +0800)
committerLuca Boccassi <bluca@debian.org>
Tue, 11 Jun 2024 23:54:26 +0000 (00:54 +0100)
commit88188e1ff1ffa2a4a41c9b8ee127f75cc03bc18d
tree47ddc836a44f777c4859b648ac515594954657aa
parentc8596cc6401f0afc7d567d517ccfbad3203b1b40
core/mount: stop generating mount units for cred mounts

While @poettering wants to keep mount units for credential
mounts, this has brought nothing but pain in real life.

By generating mount units for each cred mount, we had trouble
with default dependencies on them, which causes their stop jobs
to race with unmounting through exec_context_destroy_credentials().
There were several attempts to workaround the problem, but
none seems very graceful: #26959, #28787, #28957, #31360, #32011.
Also, we want to carry over credentials for services that
survive soft-reboot to the new mount tree, and during the practice
the stop of mount units are irritating.

The mentioned problems are ultimately resolved by disabling
default deps: #32799. But after doing that, maybe the next question
should be "why do we generate these mount units at all?"

Let's revisit the whole concept here. First of all, the credential
dirs are supposed to be opaque to users, and hence nobody should
really reference to these mounts directly. Secondly, the lifetime
of credentials is strictly bound to the service units, but nothing
else. Moreover, as more and more users of credentials pop up,
we could end up with hundreds of such mount units, which is
something we handle poorly. And we emit useless UnitRemoved signals,
etc...

As discussed, it seems that eliminating these mount units
is the correct way to go. No real use cases are impacted,
and the lifetime management becomes sane again.

Replaces #32011
src/core/mount.c