Slashdot Mirror
Systemd Rolls Out Its Own Mount Tool (phoronix.com)
An anonymous Slashdot reader writes: I'm surprised this hasn't surfaced on Slashdot already, but yesterday Phoronix reported that systemd will soon be handling file system mounts, along with all the other stuff that systemd has encompassed. The report generated the usual systemd arguments over on Reddit.com/r/linux with Lennart Poettering, systemd developer and architect, chiming in with a few clarifications.
Lennart argued it will greatly improve the handling of removable media like USB sticks.
Lennart argued it will greatly improve the handling of removable media like USB sticks.
There are systemd-free distros of Linux, you know. I can pretty confidently state that it will remain that way unless systemd should start to integrate itself into the kernel.
Well, yes... Most importantly RHEL6 / CentOS6. Those of us using Linux in business/enterprise settings are mostly running that, and that's mostly what we care about. The time limit on that is what we're sweating.
RedHat (Inc.) seems to be undervaluing its Good Will in terms of building an enterprise platform that goes well beyond RHEL subscriptions. EL users don't care about most of the systemd "feature" set (with the possible exception of easy(-ier) cgroup management), since most of the rest either doesn't apply or attempts to re-solve and already mostly-solved problem (eg, service monitoring and restart scripts). The cost is using less mature, less modular, less tested code with more common failure points, which might cover 80% of your needs but makes the other 20% of system customization really, really difficult, because apparently shell scripting is a Sin now.
Oh, and most of your config management that worked pretty similarly between EL5 and EL6 has a *lot* more of a delta to work with EL7.
"Forking Fedora" doesn't seem like it will happen, even though there are fewer and fewer non Kool-Aid drinkers there who think keeping your options open is a good thing.
Do you know what I'd like for EL8? Fork EL6, update all the non-daemon RPM versions to their current Fedora level, and run systemd as Just Another Daemon, akin to xinetd, supervise, or your cluster management software.
We get more reliable and more deterministic startup and shutdown process using the previous initscripts toolset and regular /sbin/init, and those who want the management capabilities of systemd for services can still use it, albeit with it not functioning as PID 1. I'd pay for that.
Hire a Linux system administrator, systems engineer,
Systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25s delay
https://bugs.launchpad.net/ubu...
I am sure putting all the eggs in one basket will be fine, in the long run
Self Defense - A Human Right www.a-human-right.com
No actually old farts are being hired in droves. We're not "snowflakes" in need of constant coddling and stroking. We understand we work to pay our bills and be of service to our employers... Not fulfill our dream selves. Great if our job can be fulfilling, but not really necessary.
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...).
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?!?
Other cases where it messes with filesystems are not better. 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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
[...] I get that the Unix way is to have lots of little utilities and services doing specific things, but it actually turned out to not be the best model. [...]
This is where most of the disagreement lies: It has not turned out to be the worse model. SystemD supporters are mostly concerned with the desktop (re. the user-does-stuff-with-thumbdrive rationale given for the mount manager). On the desktop, the SystemD approach makes a certain amount of sense. Though I have to strongly disagree on the notion that its implementation is anywhere near clean, hardened or tested, but given the timeframe and the ever-increasing scope that is to be expected and will likely improve over time - hell, all the alternatives it is trying to replace were shit when they came out. On the desktop SystemD is an improvement over the status quo, not the only possible venue, maybe not the ideal one, but it is here now and it mostly works.
But many Linux users care first and foremost about one use case, and one alone: the server. And on the server the UNIX way is the right way. The only sensible way, actually. On the server things like auto-mounting a thumbdrive so a user can diddle with it are not a thing. As are most other things SystemD is trying to do. Here SystemD is only one thing: a superfluous, possibly dangerous OS on top of the OS.
The balance between desktop and server has been turned over. I think it is great that the desktop is receiving more attention, don't get me wrong. But not at this cost.
Rudolf Hess edited Mein Kampf. He was the very first grammar nazi.
From Lennart's reddit comment:
"first of all, this doesn't replace util-linux' mount tool. Not at all. It just tells systemd to mount something, going through systemd's dependency logic. For the actual mount operation PID 1 will fork off util-linux' mount tool like it always did."
Big fucking deal.
Well, IMHO, it just means one more thing to go wrong. I recently had to diagnose why my agent - started via a /etc/init.d script - would not start after having been killed using "kill -9" on a systemd-based system (Deb8); running the program and daemonizing it directly worked just fine, but the init script wouldn't start it. Reason? Systemd had some state somewhere that would only get cleared if "service myservice stop" was run. Only then would the init script work.
Expect this to be similar where you'll have systemd mount something during boot, and then for some reason it gets unmounted in a way systemd didn't expect and now you can't remount it because systemd thinks its still mounted but won't tell you that.
systemd is just a piece of crap that needs to be removed.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)