We really don't want systemd to do its "dependency logic" for mounts. Case in point: have a btrfs RAID, physically remove one of its disks and mount with -o degraded. A basic operation that doesn't involve an init daemon and is impossible to get wrong, right? Not on systemd. If your RAID happens to be in fstab (ie, any real case other than when running from rescue media), systemd will helpfully instantly unmount it again. There's no known workaround for this bug other than commenting out the mount in fstab (or upgrading to sysvinit...).
If you insist on calling this a bug, unfortunately for you, that means it is a kernel bug, and more specifically a btrfs bug. And there are three workarounds :
- managing the mount manually, which is the most sensible thing to do as all your braindead operation was manual anyway;
- fixing btrfs so that it reports degraded fs as degraded, and not as dead;
- making a user space daemon that manages btrfs, like for LVM;
The most stupid thing to do is to shoot the messenger systemd, and of course, that's what most system illiterate people like you do.
And they advertise their lack of knowledge on forums to really show people how stupid they are, instead of educating themselves.
I don't get how one could possibly screw this up. So systemd runs a daemon statting all your mountpoints just so it can unmount them if it believes some dependency isn't met?!?
Like most systemd opponents, you don't know what you're talking about and it's instantly showing.
Where rsyslog goes to great lengths to ensure logs survive a system crash, sometimes even in annoying ways (like disk spinup on laptops) and uses append-only plain text logs that are readable even when heavily corrupted, systemd not only makes corruption and total data loss nearly guaranteed, but even goes out of its way to disable data consistency features (checksums, protection from torn writes, transactions) because "performance" and spams you with warnings if you manually turn them back.
It shows that you're not understanding *anything* technical, when the link you gave contradicts what you said in the same sentence. The systemd journal is doing append-only plain text logs that are readable even when heavily corrupted. One difference with other logging tools, is that systemd actually informs you when your logs are corrupted. If you even understand logs and know their history, they were always designed to not advertedly affect the OS, so that performance was always the primary goal before reliability, thus why syslogd with UDP and the like. The log system should not put your system to a halt like it did on btrfs because btrfs, well, is just not production ready yet. They actually did that because a systemd user did a bug report. A true sysadmin with a true problem, not an ignorant whiner on a forum with no understanding of Linux.