Re: Good encapsulation, Dr S
> auto-mount a network share over wifi, which was broken for years.
Oh god, SystemD and fucking mounts.
I got hit by this the other day.
Replaced a failed disk, updated fstab and ran mount. No errors, but the things not mounted.
System-mother-fucking-D was automatically unmounting it in the background. Why? Because at boot, it reads in fstab and creates a unit for each mount.
At boot, fstab said that /dev/sdb (or whatever) should be mounted at /foo. So there's a unit saying that /dev/sdb goes to /foo. /dev/sdb no longer exists, so that unit's automatically inactive.
fstab now (correctly) says that /dev/sdc should mount to /foo. So when you run mount, that's exactly what happens.
But then systemD sticks it's grubby little nose in, decides it's a conflict and unmounts the fucker, quietly pushing 2 lines into the journal. Not dmesg though, no. Unless you run journalctl you won't see it.
Turns out, you need to do a systemctl daemon-reload to make it go and regenerate the units.
Unsurprisingly this annoyed me, then I found the SystemD bug and saw it had annoyed others to. Still not fixed, but there is a "workaround" listed in there for when a daemon-reload doesn't work (as is apparently sometimes the case):
> Remove the line from /etc/fstab and mount it manually (or use a startup cronjob script).
SystemD is fucking useless.
Based on the reports in that bug, Poettering should be less concerned about whether someone can decrypt his home after suspend, and more concerned about whether he'll be able to mount the fucking thing after a suspend.