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.

Re:heck with linux..

[Provocateur]

it comes with a convenient tool to place it on a bootable USB stick, and it's called
uwontbootin
to avoid confusion with unetbootin, of course.

Re:heck with linux..

[sexconker]

Should've gone with unotbootin.

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?

[fahrbot-bot]

I think it is like Emacs without the editor part.

Emacs has been around since 1976 -- I've used it almost daily since 1985. Let's see if systemd is still here and useful in 40 years.

Re:SystemD?

[lucm]

I think it is like Emacs without the editor part.

Emacs has been around since 1976 -- I've used it almost daily since 1985. Let's see if systemd is still here and useful in 40 years.

You're like the senior management at Blockbusters who saw Netflix as a minor niche player who presented no threat to them. Or like the managers at Polaroid who thought digital cameras were just a fantasy.

Systemd is a cancer and it will keep spreading until the host is dead. Just like cancer it's not malicious, it sincerely believes it knows better than the healthy cells it's infecting, but that doesn't make it less lethal.

Re:SystemD?

[chipschap]

You need to check out the various emacs related mailing lists, which are very active with a lot of people involved.

Emacs is still around, and more useful than ever.

Re:SystemD?

[jeremyp]

Not heard of systemd-emacs? It has the advantage that all your editing sessions are spawned directly off process 1. No need to su anymore to edit /etc/passwd.

Also, you can have dependency management so when you invoke systemd-emacs, systemd will make sure that the emacs vi emulator extension is installed first.

Re:SystemD?

[l3v1]

"What ever happened to the principle of single responsibility? Where a tool does one thing and does it well, and you put tools together to do whatever?"

It does one thing [questionably] well, problem is that that one thing is called "everything" :P

Re:SystemD?

[CronoCloud]

Leaving discussion of emacs and systemd (though I run a systemd distro) aside, I did have to comment on this:

although personally I prefer vi

vi? What are you, some suspender wearing greybeard who still uses an ASR33, and calls bicycles "velocipedes"?

vi is archaic and arcane. What you should be using is....vim. ;-)
In fact vi users these days probably are actually using vim-minimal.

Yes I know, vi as vim-minimal is installed by default, on Linux anyway, and vim-enhanced isn't. /me waits for a low 4 digit UID guy to extoll the virtues of "ed".

Re:SystemD?

[lucm]

Everything in the software world is moving toward micro-services and loosely coupled components lately, but with Linux and Systemd it's the exact opposite. Isn't that funny?

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]

Indeed. The only ones upset about this are the ones that did not know what it was about.

Re: Does not replace mount

[Anonymous Coward]

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

Re: Does not replace mount

[DrXym]

Yes it is better as a read of the link would quickly show. It allows a user to plug in a USB stick, mount the device, mount the FS, schedule an fsck and reduce the danger if the user unplugs the stick without an explicit unmount.

Re:does not replace mount

[houghi]

.... so far. The next stap will be "Hey, we wrap it already, why not put it in there as well.

The system is started with a bootloader that treis to do everything to run an init that tries to do everything that has a GUI that tries to do everything to run a desktop that tries to do everything with in it a brower that tries to do everything to look at a website that tries to do everything.

Where is the tme that each piece of software did their seperate part and did that well. And if I wanted to change that piece, I did and it STILL worked.

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.

Re:Does not replace mount

[TemporalBeing]

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.

Re: Does not replace mount

[Anonymous Coward]

Yes it is better as a read of the link would quickly show. It allows a user to plug in a USB stick, mount the device, mount the FS, schedule an fsck and reduce the danger if the user unplugs the stick without an explicit unmount.

Neither you, nor the link, have described anything “better” (or for that matter, “new”). It's also pretty clear that you didn't actually read the link, or you would know that very little described in the link will actually protect anyone from pulling a flash drive out before it's been cleanly unmounted. The problem with slow flash media is (and has always been) that a considerable amount of "written" data is buffered before actually being flushed out to disk. There is nothing systemd-mount can do about that. If the flash drive is no longer plugged in, you can't flush the unwritten data to it, because it's physically not there anymore. No amount of on-access fscking is going to bring that data back. What an on-access fsck will do, is try to make sure the filesystem is at least mountable. Nothing more. It doesn't decrease the danger of an unplug without unmount at all, it tries to tidy up a bit after the real damage has already been done, and does so without letting the user know the scale of the damage. Out of sight, out of mind. A very Lennart solution.

Now, take the rubbish about unsafely unplugged USB drives/on-access fsck out of the equation for a second, and what does systemd-mount actually provide? It provides better systemd integration. Nothing described in the link is unique to systemd, not even the possibility of on-access fsck. We've gone from a system where we can fully script every aspect of the start-up process, to one where you need to write code to integrate well, and half of the smaller jobs are being undertaken by the project itself because nobody can be bothered. What a gross monster we've created.

Re: Does not replace mount

[silanea]

No. My argument is that on the server, many of systemd's components are either solutions in search of a problem or trying to solve real problems the wrong way. It started with things like accepting log corruption in return for faster performance. On most desktops, that is a justifiable trade-off. On a server, it is a minority use case. With a really tiny minority on whose servers I for one would not be willing to rely.

As I said: systemd is acceptable for desktops or other user-facing systems. Things that you expect to break anyhow because of user dumbness, hardware failure or spilled coffee, where reinstallation or replacement is cheaper and more practical than investing in reliability. There it brings you net benefits due to its design trade-offs. On a server I want to be able to retrace why something failed, not just have the system go back to some mostly functional default state or take a guess at what might be the best way to proceed. On a server I need to trust the system to do exactly what it is supposed to do, and to do it not just once or twice but every single time.

I know that it has become a bit of a trend to treat servers like just another machine and simply redeploy instead of fixing issues. For many business cases this may be the more economic solution. It is not the one I consider sensible and future-proof.

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

[ultranova]

According to Slashdotters, everything must be done as it's always been done, regardless of any externalities.

Which is kinda ironic for a forum once centered around new technology. We've gotten old :(.

Re:Wrapper, not replacement

[PPH]

Just a wrapper around mount. I don't have a problem with that. What does bother me is that Lennart and company have only figured out this late in the init game that mounting is something that we need done. Great. Go for it. You've still got a dozen or so other things that need to be handled (which scripts have been doing for ages). We will sit back in amusement and watch as you find yet another function that you've forgotten about. And rush to build yet another wheel or lever into your Rube Goldberg contraption.

Re:Wrapper, not replacement

[Sarten-X]

There are already the usual anti-systemd flames and complaints about how it's absorbing ever more functionality.

As for the server itself, that is roughly the current plan. The devil's in the details, though, when it comes to handling errors in detecting the network configuration and mounting the remote filesystems. For example, as node A initializes, it should try to connect to (and mount) nodes B, C, and D, but if a node is down, the other node connections should function normally until the missing node returns, at which time that connection should be established and the data synchronized among the nodes.

Writing standard scripts to handle the process isn't an intractable problem, but it'd be much simpler with a more robust environment. I'm curious (and a bit hopeful) to see whether systemd can provide the necessary functionality without extensive custom scripting.

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]

Yes... and ought to. It's a job that absolutely belongs in a desktop environment and absolutely does NOT belong any lower in the stack than that - because there is no universally 'correct' way to deal with removable media - the common pattern is ONLY correct in a D.E. - lower in the stack any number of options could be correct for the use-case up to and including completely preventing the mounting of any removable media for security reasons.

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.

Re:Linux is far worse than Microsoft

[Noryungi]

yadda yadda yadda.

Linux does not "force" you into anything: systemd is still optional and many linux distros run perfectly well without systemd (including my old friend Slackware).

And if you really don't like Linux, there is always the BSD. Nope, no systemd there, no sirree.

So anyway... yeah, you have no idea what you are talking about.

Re:Linux is far worse than Microsoft

[mark-t]

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.

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

When the only tool you have is a hammer...

[QuietLagoon]

Lennart argued it will greatly improve the handling of removable media like USB sticks.

... everything starts looking like a nail.

Re:When the only tool you have is a hammer...

[fahrbot-bot]

Lennart argued it will greatly improve the handling of removable media like USB sticks.

... everything starts looking like a nail.

When you hear hoof-beats, you think systemd, not zebras - wait... "horses". Whatever. It's *something* people will still want to beat after it's dead. Maybe I'm thinking about Lennart...

When everything you do

[RightwingNutjob]

invited complaints, counter-arguments, and forks to get away from your shit, maybe you should take that as a hint to just stop. Chances are that you are, in fact, not the only sane man left.

Re:When everything you do

[mark-t]

To play devil's advocate, consider that heliocentrism was pretty widely ridiculed (to put it mildly) when it was first proposed, and it took centuries before it was eventually accepted as fact.

Re:When everything you do

[johannesg]

So why are so many distros using it? Maybe you should just take that as a hint to take it more seriously?

What is the actual problem of using systemd as a mount tool? I've read the entire thread and not seen a single complaint other than the fact that it is "systemd by leonart poetering", which to me seems like an extremely childish case of shooting the messenger.

Re:When everything you do

[Entrope]

Having robust, testable, easily isolated components is even more important when you have a complex system -- and the way you get those is by defining the one thing that each component should do, and making it do that thing well.

Have you ever tried to debug something that has both complex components and complex interactions, either between the components or with external entities (people or machines)? Very frequently, if the designer decomposed it well, the nature of the failure will make it pretty obvious which part is failing. systemd fails in that department; just look at a few of the thousands of bug reports against it.

Re:When everything you do

[Junta]

The thing is it works well, until something cocks up, then it's utter hell. The non-deterministic boot process is killer. I have had a hell of a time diagnosing systems where people have done things so root filesystem will not mount on normal boot. Then I try to boot single and it works fine, or rdshell. It turns out to be some crazy ass race condition between two things *no one* realized would be related, or should be related.

Also, things that were straightforward get strangely complicated. SysV init didn't care one bit about something like docker, but a lot of work and complication went on to coordinate systemd and docker.

I have more admins than ever requiring support and I can't fault them for being unable to contend with the mess they have been saddled with. It's more featureful, but it takes things too far making a lot of things impossible to reasonably debug. I personally would love to see journald eschew the binary-only logging and for systemd to offer a deterministic boot mode, where boot speed is compromised for the sake of repeatability.

It's not just old folks whining about change,, there are very concrete things that are being done incorrectly. Sure there are more nebuluous rants that may be either folks trying to get a rise out of the community or have a difficult time expressing their general frustration in a more concrete ways, but that's no reason to sweep the real problems under the rug along with them.

Re:When everything you do

[slack_justyb]

Define component then.

Scripts might have not been a single monolith, but they sure functionally acted as one. Most admins tossed crap in rc.local because touching the actual init scripts was playing with black magic.

You can make write a single object file to do one thing and do it well. You can then take several other one thing done well object files and compile them into a library of really useful stuff. Does this act of compiling them all into a single thing suddenly break the one thing done well ethos of the objects within? So this whole thing of one thing done well, is just people cutting arbitrary lines in sand.

systemd fails in that department; just look at a few of the thousands of bug reports against it.

That's a ridiculous metric. The project is a very large one and projects of similar size have large amounts of bug reports as well.

Very frequently, if the designer decomposed it well, the nature of the failure will make it pretty obvious which part is failing.

Which is why we dumped scripts, trying to make heads of tails of where a change went wrong took an inordinate amount of time of swimming through script after script to see where the one thing that was supposed to be done, didn't happen. The very arguments that you've used against systemd are the exact same ones leveled against the very thing that everyone seems so damn certain to want to go back to. I'm just fully convinced at this point that haters going to hate and that's all there is to it.

Re:When everything you do

[Entrope]

I was using the common CS definition of component. The lines are not arbitrary at all.

Your misinterpretation of what I said is the ridiculous thing here. The number of bugs reported doesn't indicate why it's a failure of software design -- the nature of those bugs do. But you'd have to do what I said, and look at several of them to follow the finger-pointing and confusion about root causes, to know what I meant.

The fact that systemd has now centralized and complicated a fragile arrangement does not make it an improvement.

Godwinned in just 17 minutes.

[mark-t]

Not a record... but still pretty impressive.

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.

Lennart P., if you're reading this?

[Anonymous Coward]

See subject: DO NOT STOP - you're winning man... the shellscript kiddies are scared shitless & worried about their TENUOUS "job security" since you largely eliminate their homemade custom scripts via your tech!

APK

P.S.=> DO NOT STOP... apk

Re:Linux

[Vlijmen Fileer]

"Canonical"?
Isn't that that sect that makes Babylinux^DUbuntu?
If you're using that you have a whole different sort of issue to solve first.

Re:Linux is far worse than Microsoft

[Anonymous Coward]

fuck off retarded, nothing optional about that shit

= 'I don't know a fucking thing about it but I hate it anyway.'

Re:Adolf hitler, lennart p, donald t

[PopeRatzo]

Adolf Hitler, Lennart Poettering, Donald Drumpf. All of german / austrian origin, and all horrible criminals.

But at least Adolf Hitler never used systemd. And few people know that the fuhrer was a terrific dancer, and could paint an entire apartment in one afternoon...two coats!

https://youtu.be/D6llaZefJDc

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.

does not replace mount

[JonathanP.Bennett]

When I first read this on Phoronix, it appeared that systemd was replacing the mount command. This is not the case. It is wrapping the mount command. That seems to be an important distinction. Replacing mount would be crazy and pointless. Handling mounts more intelligently during startup would be welcome. So far, this seems to be the latter instead of the former.

Re:and in other news...

[Anonymous Coward]

Well duh, of course systemd will have its own editor. How else are you going to be able to fix your configuration when the system won't boot? Do you think that Lennart will ever add a keystroke to cancel starting a broken unit during boot? I mean, you could ctrl-c most service startup scripts in SysV init, and if init could do it, then it must be wrong.

Slack Off

[flyingfsck]

I use Slackware, so I don't need to know what it is all about. Thanks Pat!

Hmmm how bad could it be?

[birukun]

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

Re:Hmmm how bad could it be?

[swillden]

Systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25s delay

https://bugs.launchpad.net/ubu...

Except... it wasn't a systemd bug at all. Per comment #16:

Ok, with everyone confirming that the systemd patch is not required, I am closing the systemd part of the bug as 'Invalid' - let's only concentrate on the dbus part here. That being said, I would not like to release a new patch for dbus downstream if the patch hasn't been fully reviewed and approved upstream. In this case I would propose to wait a bit and see if a finalized patch will be available.

Not that the presence of one bug in systemd would indicate that the whole approach is a bad idea... but it's rather funny that the one example you pick turns out not to be a systemd bug at all.

Re:Linux is far worse than Microsoft

[Eristone]

Some of us actually know how to do more than yum -y install. You know -- that old fashioned "compile from source"? Or even find an rpm.

Re:Devuan is a Debian distrro not shipping system

[maglor_83]

What the hell is a "disttro"?

It's a misspelling of 'distrro', which is itself a misspelling of 'distro', which is a shortened form of 'distribution'. Glad to be of service.

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

[Tailhook]

a major distro with systemd removed (with broken functionality)

While this is mostly true for those hosting their own systems, one of the larger pieces of the Linux `ecosystem' today is AWS. The heavily used Amazon Linux AMI has the traditional SysV init and Amazon has not indicated that they intend to move to systemd. This at least ensures that it will not be possible to entirely neglect SysV init methods; if it doesn't run on EC2 it's broken for many people, and indeed there are cases of commercial software vendors discovering that their paying customers need SysV init compatibility for this reason.

I personally haven't had problem with systemd anywhere I've had to deal with it, and I've become comfortable working with it. The doomsayers predicted all manner of problems with systemd. They were wrong as far as I know. A minor bug here and there, quickly fixed. Journalctl is very handy; a lot nicer than chasing creatively named log files hither and thither. On the other hand, when I deal with EC2 instances and SysV init I'm fine with that as well. I understand both the rational for systemd and the reasons behind Amazon staying with SysV init; I'm happy to live with both.

Re:Linux is far worse than Microsoft

[lucm]

Some of us actually know how to do more than yum -y install. You know -- that old fashioned "compile from source"? Or even find an rpm.

The point is not "duh give me teh rpms", the point is why the fuck would you pay $2,000 per cpu per year to get a polite "piss off" from Red Hat whenever support is needed because you installed (from source or other) a version or software that is not in their repo. That's like renting a car that has no radio and bragging that you can go to Best Buy to get a car radio installed in it.

If you want the general Red Har ecosystem but you rely on non-supported software, use CentOS for free and be done with it.

Re:Linux is far worse than Microsoft

[Anonymous Coward]

fuck off retarded, nothing optional about that shit

You know you have won when the other side resorts to profanity.

Sigh.

[ledow]

Anyone else read the bit about automatic fsck of FAT filesystems on USB insertion?

I'm presuming that it'll be optional but still - way to fuck everyone's USB sticks and SD cards up.

Auto-fsck is a stupid idea. At worst, do it read-only and warn (like Windows does). But just fixing up the filesystem without asking the user first? A good way to trash stuff.

Re:Sigh.

[gweihir]

Same quality-level as the rest of this malware...

I'd like to share a revelation I've had...

[sciengin]

I'd like to share a revelation that I've had during my time here. It came to me when I tried to classify systemD and I realized that it is not actually software. Every software package on Linux instinctively develops a natural equilibrium with the surrounding environment but SystemD does not. It moves to an area and multiplies and multiplies until every other service is consumed and the only way it can survive is to spread to another area. There is another organism on this planet that follows the same pattern. Do you know what it is? A virus. SystemD is a disease, a cancer of this Platform. It is a plague and we are the cure.

[Lobby Scene follows]

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.

Re: Linux is far worse than Microsoft

[Entrope]

Outsourcing security ("as a service") seldom works out well in the end.

Re: Linux is far worse than Microsoft

[silentcoder]

You clearly have no idea what a strawman argument even is. You took the adoption of systemD by distro maintainers and made a claim (with no evidence) to explain it.
I merely pointed out how meaningless your claim is.
I didnt misrepresent your argument by focussing on a tiny bit of it. I addressed everything you said.
Its not a strawman when your argument really was that weak.

Re: Linux is far worse than Microsoft

[aquacrayfish]

I don't normally like interjecting discussions between people, but at least read what the person said. On the smaller point, the analogy was pretty damned clear if you just read the sentence before that. The larger point ties into not knowing what a straw man is. Your claim was that it was better for maintainers, while the counter was that, despite that being true, it can and has been argued that systemd is not necessarily better for users. That assertion is not predicated on contradicting an earlier statement. It was building on your original claim (users vs maintainers).

You may disagree that it isn't better for users, but it depends on what metrics you choose. A lot of people don't think so. If you disagree that users don't have it better with systemd, then defend that stance.

Simple question to those knowlegable of SystemD

[Qbertino]

Simple honest question to those knowlegable of SystemD

Ok, to I want to do this (I'll try using generic laymans terms so I dear not insult anybody using the *wrong* technical term):

I'm using Linux (Ubuntu 16 LTS to be precise) and this computer of mine boots up as wanted. So far so good.
Now, when the computer has finished booting, I want to launch a script or a set of scripts that in turn launch some programms I want to launch upon boot. I'm talking non-pointy-click-user autolaunch here, like maintainance stuff, developer servers & databases, special tools running in the background etc.

And here's the question:
How do I do this on/with SystemD? What do I need for it and what should I know / what concept do I have do grasp to achieve this?

To give an impression of what I'm used to:
There used to be this thing called "init process" on Linux that had another thing called "runlevels". A runlevel basically was a set of incrementally named scripts in a directory with basically the runlevels number as a name. You would edit the scripts in that directory to do what you wanted (or add your own script with an incremental number) and then launch said runlevel typing "init [RunlevelNumber]" in the cli.

I wonder how this goes in SystemD and how complicated it may be. Is there a GUI Tool for this? I heard that these scripts are basically binaries in SystemD and I have to compile them? Is that true?

Please help me add my on "launch-stuff" to SystemD, and please give me the easyest way that is still in the area of the "SystemD" philosophy.

Thanks for your help.

Re:Simple question to those knowlegable of SystemD

[LichtSpektren]

systemd supports old shell scripts. The easier way is to make a unit file: https://wiki.archlinux.org/ind...

No auto-fsck please...

[Junta]

Unless you run it in check-only mode. I have seen systems blindly try to detect and *correct* problems in a filesystem cause tremendous harm. Even Windows prompts the user before taking such measures on removable media. The fact of the matter is you may have some unexpected situation that would be corrupted by that action. Maybe a newer version of the filesystem your version of fsck mistakens for corrupt. Maybe it had one type of partition table at some point now it has a new one you don't recognize, but you see a backup block and corrupt the storage by restoring backup block of what you do recognize.

The fact of the matter is, users should be asked/made to take corrective action in something like fixing a filesystem.

Re:Linux is far worse than Microsoft

[TemporalBeing]

There are major distros that are systemd free, and not only because systemd was removed from them, but because they never had it (Slackware)... or at least only have it as a non-required option (Gentoo).

Well according to Distro Watch Slackware rates 16 and Gentoo rates 36 on the list of page hits so they must be major distibutions.

Consider this: Slackware is the last of the original Linux distros still active, with updates, etc. It's the origin for numerous distros - including many other major distros. Its authors are some of the top and moist respected in the LInux community.

Gentoo is the first real major source-based distro, and the origin distro for numerous other distros, the most famous being ArchLinux.

Know your distro history before trying to downplay the role a distro has.

Systemd the distro

[lucm]

Great! What can we do to speed up this process a bit, its about time that linux started to replace some of its aging, creaking old architecture with new tools liberated of old, out of date practices and effectively made a system which took care of the things I really dont give a shit about.

My computer is not my work, I use it to do my work, I do not want to spend time configuring it, I want to spend time doing my work and enjoying myself, I really couldnt give a fuck how to configure it 90% of the time.

I think you summarize the problem pretty well. Systemd is a desktop solution for people who essentially want a Macbook.

What would be great? Having systemd only in specialized desktop distributions. Not on servers and not on desktop for power users. Even better: systemd should be a distribution itself, not be a part of other distributions. And it would also have the exclusivity of pulseaudio.

Re:and in other news...

[TWX]

Am I the only one who cares that systemd is following the path of much of the rest of the Linux ecosystem in adding more and more features before bothering to extinguish all the bugs in the existing feature set? Has it proven that it should be gobbling up other features and breaking the old UNIX model of discreet chunks of competent tightly-focused code yet?

No, you're not the only one. I'm installing new boxes at home with Devuan because I like my Linux boxes to use Init. I am aware that this will be the more difficult path, but Debian seems to have violated its own rules regarding adding new packages to Stable after it's made stable.

I do not like all-in-one solutions, and my experiences with random problems with PulseAudio leaves me distrustful of other software from the same developer, and to me this looks like fixing something that isn't broken.

If Systemd becomes ubiquitous and unavoidable I'll look at other UNIX/UNIX-Like operating systems.