It's hard to tell what this is really about. Is it that systemd just assumes that it must have itself mounted the volume some daemon announced a dependency on (because who else would have?), so should unmount that when it thinks the daemon failed?
Is this because it has no way of recording whether the thing was already mounted when it started fooling with the daemon? Or, that it has no way to know that you wanted to keep it mounted, because you "failed" to turn on a service that depends on the thing remaining mounted?
And, why is behavior different in different distros? Which ones still have the bug (or lack a workaround), which don't?
3 comments
[ 2.7 ms ] story [ 18.1 ms ] threadIt's hard to tell what this is really about. Is it that systemd just assumes that it must have itself mounted the volume some daemon announced a dependency on (because who else would have?), so should unmount that when it thinks the daemon failed?
Is this because it has no way of recording whether the thing was already mounted when it started fooling with the daemon? Or, that it has no way to know that you wanted to keep it mounted, because you "failed" to turn on a service that depends on the thing remaining mounted?
And, why is behavior different in different distros? Which ones still have the bug (or lack a workaround), which don't?
7 years, gets censored instead of a fix. Systemd ladies and gentlemen, you get the D.