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.

Comments

heck with linux..

[Anonymous Coward]

we should all just install systemd and be done.

Re:heck with linux..

[sconeu]

Systemd would be a a great OS... all it needs is a decent init system.

Obligatory parseltongue

[Anonymous Coward]

Lennnnnnnarrrrrt Potttttterrrrrrr

SystemD?

[Nethead]

I keep hearing about this SystemD thing. Is this the OS that Linux runs on?

Re:SystemD?

[110010001000]

I think it is like Emacs without the editor part.

Re:SystemD?

[Anonymous Coward]

That would be funny if it weren't true.

Re:SystemD?

[DeVilla]

/me waits for a low 4 digit UID guy to extoll the virtues of "ed".

You've got me boxed in a corner here.

Does not replace mount

[Anonymous Coward]

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.

Re: Does not replace mount

[Anonymous Coward]

So it's subsumed the auto mounter. That is no better.

Re:Does not replace mount

[KiloByte]

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.

Re: Does not replace mount

[silanea]

[...] 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.

Wrapper, not replacement

[Anonymous Coward]

This is a new wrapper around the existing mount tool. Systemd is changing how it mounts things to standardize that portion of jobs, and it's also handling auto-mounting of external media, like your desktop environment probably already does. has done for ages.

Re:Wrapper, not replacement

[Sarten-X]

Yep. That won't stop the hivemind from shouting against it, though. According to Slashdotters, everything must be done as it's always been done, regardless of any externalities.

Meanwhile, I have a server (based on an ugly inherited design) that has to figure out its remote filesystems based on the network structure, as determined by a user-run script. The process I inherited was to boot the server, run the script, then mount the filesystems it reported needing. Then and only then could the main daemon be started manually.

Fuck that.

An upcoming rework will automate the process with scripts, but it seems like the sort of thing that falls right in systemd's wheelhouse. Systemd's goal is to start the system services, which would reasonably include my daemon. It therefore also seems reasonable that systemd could have access to mounting functions, to ensure the system is ready to start that daemon.

Re:Wrapper, not replacement

[lgw]

Systemd objections are not about "any change is bad". They're about "this change is bad".

Re:Wrapper, not replacement

[silentcoder]

Indeed. We didn't mind simpleinit, or upstart or openRC or slackware's BSD-init - all of these were different init systems in the past. We didn't mount autofs or any of a dozen mount helpers added on top of the unix basic during the years.

To suggest that the opposition to SystemD is generically opposing change is to ignore that the people opposing it have been embracing change in all the areas where it plays for decades and are STILL embracing change in those areas - we're just not embracing THIS change because we believe it's badly designed. Having this many basic tools in a common code-base with massive interdependency that makes it near impossible to swap tools out with other tools or run any of them without running all of them... THAT Is a terrible design.

Hell, we don't even do that on the desktop where it may almost make sense. For over a decade KDE has had performance improvements if you run KDE apps in a KDE desktop - but never, once, did we have a KDE app you couldn't run under Gnome or OpenBox or any other DE you want. The coupling was always weak - use the features when available, don't depend on them. And vice versa - all the apps ran under all the desktops. You didn't struggle to run gimp or libreOffice if you chose KDE as your desktop - despite neither of them being written for it. In fact, there were patches you could install to integrate them better which were entirely optional.

That's a good design.

Re:Wrapper, not replacement

[silentcoder]

You know it's weird, but there is literally not a single thing on your list that Linux hasn't been used for successfully and doing successfully for the better part of 20 years. None of these are new problems. So since systemD is only 6 years old and most major distro's didn't adopt it until the last 3, I guess all of us were just suffering some mass delusion when we watched all this stuff working beautifully back in 2000 when nobody had ever concevied of systemD - and progressively get better every year since.

Now nobody is saying that there cannot be better solutions for this - what I can tell you is that a better solution CANNOT come from a massive bunch of tightly coupled tools with opague interfaces that are so utterly cross dependent that none of them can run (at least without massive hacks) unless you also run all the others.

The ONLY way to EVER do a good solution - especially at the system level - is to build it out of lots of LOOSELY coupled tiny bits that don't care how you put them together or what you put them together with (including pieces that the creators never knew existed).
That design has allowed an OS first compiled in 1969 to scale to the largest supercomputers and the smallest embedded devices alike, to survive 50 years of computing history jumping from platform to platform and architecture to architecture, resilient across one major revolution after the other - because it could adapt to any need and any use-case. Because you never had to redesign it to meet a new challenge, you just had to add a few small tools to the mix, and put the others together in a new way.

The lego-blocks approach is the heart and soul of the unix philosophy - and it's a philosophy worth preserving because that philosophy is literally the ONLY thing that has caused Unix to be the single longest-living architecture in computer history. It's an architecture that's so easy to evolve that no revolution was out of it's reach. From mainframes to PC's to phones - it went where the hardware went and was consistently the most reliable and cheapest and fit-for-purpose answer because it was designed to be easy to rebuild by simply taking the blocks and hooking them up in a new way that Kernighan and Ritchie never imagined.

In other words - everything SystemD is not.

We love doing things in new ways, we love change - but we're GOOD at spotting the difference between progress and regression - and systemd is NOT progress, systemD is doing on Linux the exact same mistakes that every operating system besides unix in history has made. If it remains dominant too long - the outcome will be that Linux goes the way of Multics or VMS because, like those, it will not be able to survive the next revolution.

Devuan is a Debian distrro not shipping system d

[chris2net23]

Devuan is a Debian distrro not shipping system d. I only know about it because it's supported by the EOMA68 project which aims to manufacture computers based around a modular computing standard that is free software friendly. Unlike Intel/AMD: https://www.crowdsupply.com/eo...

Re:Linux is far worse than Microsoft

[Etcetera]

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.

Re:Linux is far worse than Microsoft

[Dagger2]

Realistically, the Linux ecosystem forces you to pick between running a minor distro that you don't want to use, running a major distro with systemd removed (with broken functionality) or giving up and using systemd.

I suppose you could technically call that "not forcing" on the basis that you made the choice to use Linux in the first place, but... nope. Still being forced.

Re:Since '85?!

[bferrell]

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.

Re:Linux is far worse than Microsoft

[silentcoder]

Better for distro maintainers != better for users or better for Linux.

Better is an ENTIRELY subjective thing. Better at what ? Better *how* ?

Whether something is demonstrably better depends on what your chosen measurements are. That's like saying a Boeing 747 is demonstrably better a motorcycle.
Whether or not the statement is true depends entirely on the job description. If the job description is 'ferrying lots of people from coast to coast" then it's true, if the job description is "getting to the other side of town with minimal traffic problems" then it's utterly false.

No systemd is NOT better than anything by many, many measures. The only thing it is consistently better at is making distro maintainers' jobs easier. That's not a bad thing, but it's the wrong metric. Here in my country we have a similar issue in the medical insurance field. The largest local insurer by a long shot is also demonstrably the worst insurer you can have. They frequently refuse to pay claims they are liable for (relying on the imbalance of power their wealth gives them should a client choose to sue). Their customer service is absolutely atrocious.

So how the hell did they get to be the biggest insurer ? Because the deals they offer employers is demonstrably the best in the market. They save employers lots of money, so employers make them the default insurance offered - and employees are stuck with the worst insurance imaginable.

That's pretty much the relationship with systemd and distro-maintainers versus users.