Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×
Debian Open Source Operating Systems Red Hat Software Software Ubuntu Linux

Systemd Rolls Out Its Own Mount Tool (phoronix.com) 541

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.
This discussion has been archived. No new comments can be posted.

Systemd Rolls Out Its Own Mount Tool

Comments Filter:
  • by Anonymous Coward on Sunday August 21, 2016 @08:36PM (#52745223)

    we should all just install systemd and be done.

  • by Anonymous Coward on Sunday August 21, 2016 @08:37PM (#52745237)

    Lennnnnnnarrrrrt Potttttterrrrrrr

  • SystemD? (Score:5, Funny)

    by Nethead ( 1563 ) <joe@nethead.com> on Sunday August 21, 2016 @08:40PM (#52745247) Homepage Journal

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

    • Re:SystemD? (Score:5, Funny)

      by 110010001000 ( 697113 ) on Sunday August 21, 2016 @08:46PM (#52745273) Homepage Journal
      I think it is like Emacs without the editor part.
      • Re:SystemD? (Score:5, Insightful)

        by Anonymous Coward on Sunday August 21, 2016 @08:52PM (#52745305)

        That would be funny if it weren't true.

      • 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? (Score:5, Insightful)

          by lucm ( 889690 ) on Sunday August 21, 2016 @10:04PM (#52745591)

          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.

        • by Alomex ( 148003 )

          Your post seems to presume that emacs is (1) still around and (2) useful.

          I think both of those statements are rather questionable. A few legacy users do not qualify as "still around" and even though I used emacs for nearly ten years back in the 90s, today you couldn't pay me enough for me to use it. I've read elsewhere that this seems to be the norm, and people have migrated to graphical environments for most purposes falling back on vi when they only need a text editor.

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

      • There's an Inception joke to be made here.

        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?

        • by l3v1 ( 787564 )
          "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
      • by jeremyp ( 130771 )

        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.

    • by AHuxley ( 892839 )
      A lot of well working, smaller programs and aspects of the OS are now part of something new.
    • by Archfeld ( 6757 )

      https://en.wikipedia.org/wiki/... [wikipedia.org]

      Just in case you were NOT trolling...

    • by Z00L00K ( 682162 )

      It's more like an operating system that runs on top of Linux than anything else.

  • by Anonymous Coward on Sunday August 21, 2016 @08:41PM (#52745253)

    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: (Score:2, Insightful)

      by Anonymous Coward

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

    • by Anonymous Coward on Sunday August 21, 2016 @09:54PM (#52745551)

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

      • by DrXym ( 126579 ) on Monday August 22, 2016 @04:03AM (#52746443)
        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.
        • by Anonymous Coward on Monday August 22, 2016 @09:21AM (#52747901)

          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.

    • by KiloByte ( 825081 ) on Monday August 22, 2016 @05:59AM (#52746719)

      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 [github.com] (checksums, protection from torn writes, transactions) because "performance" and spams you with warnings if you manually turn them back.

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

  • by Anonymous Coward on Sunday August 21, 2016 @08:44PM (#52745265)

    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.

    • by Sarten-X ( 1102295 ) on Sunday August 21, 2016 @09:14PM (#52745395) Homepage

      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.

      • by ultranova ( 717540 ) on Sunday August 21, 2016 @09:39PM (#52745491)

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

      • by sjames ( 1099 )

        I'm not seeing a lot of shouting.

        Meanwhile, since you'll have to re-do the startup on that server anyway, why not just have that script go ahead and mount the filesystem it says it needs and then run the main daemon? That way it will run anywhere. Then just call that from an init script.

        • by Sarten-X ( 1102295 ) on Sunday August 21, 2016 @10:55PM (#52745743) Homepage

          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.

      • by lgw ( 121541 ) on Monday August 22, 2016 @02:46AM (#52746267) Journal

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

        • by silentcoder ( 1241496 ) on Monday August 22, 2016 @04:27AM (#52746501)

          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.

    • by PPH ( 736903 )

      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 contrap

    • Re: (Score:3, Insightful)

      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.

  • by Chris ( 4631445 ) on Sunday August 21, 2016 @08:50PM (#52745297)

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

  • by QuietLagoon ( 813062 ) on Sunday August 21, 2016 @08:54PM (#52745315)

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

    ... everything starts looking like a nail.

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

    • by jrumney ( 197329 )
      ... everything starts looking like a thumb.

      FTFY.

  • by RightwingNutjob ( 1302813 ) on Sunday August 21, 2016 @09:00PM (#52745345)
    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.
    • by mark-t ( 151149 )
      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.
    • by ljw1004 ( 764174 )

      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.

      I honestly can't tell whether you're saying Poettering should stop (since systemd generates so many complaints), or the naysayers should stop (since systemd is so widely adopted and the naysayers aren't the "only sane ones left").

    • by johannesg ( 664142 ) on Monday August 22, 2016 @01:45AM (#52746113)

      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.

  • Next month: Systemd rolls out its own Linux

  • by Anonymous Coward on Sunday August 21, 2016 @09:13PM (#52745393)

    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

  • ...I'm surprised this hasn't surfaced on Slashdot already...

    I wish it did, but you just had to go and submit an article about it. I thought there was great hope in /.'ers to stop responding to systemd news and we finally stopped feeding the bear and it, indeed, went away...... from our rss feeds.

    Unfortunately, the bear lives on.

  • by Jonathan P. Bennett ( 2872425 ) on Sunday August 21, 2016 @09:45PM (#52745515)

    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.

    • It does seem to be replacing automount though.

    • by houghi ( 78078 )

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

  • by birukun ( 145245 ) on Sunday August 21, 2016 @10:32PM (#52745683)

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

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

    I am sure putting all the eggs in one basket will be fine, in the long run

    • by swillden ( 191260 ) <shawn-ds@willden.org> on Monday August 22, 2016 @08:11AM (#52747377) Homepage Journal

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

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

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

      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.

  • by ledow ( 319597 ) on Monday August 22, 2016 @03:19AM (#52746339) Homepage

    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.

  • by sciengin ( 4278027 ) on Monday August 22, 2016 @04:25AM (#52746495)

    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]

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

  • by Junta ( 36770 ) on Monday August 22, 2016 @08:27AM (#52747507)

    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.

New systems generate new problems.

Working...