Stories
Slash Boxes
Comments

SoylentNews is people

posted by CoolHand on Wednesday October 05 2016, @12:46AM   Printer-friendly
from the love-for-lennart dept.

Security researcher and MateSSL founder, Andrew Ayer has uncovered a bug which will either crash or make systemd unstable (depending on who you talk to) on pretty much every linux distro. David Strauss posted a highly critical response to Ayer. In true pedantic nerd-fight fashion there is a bit of back and forth between them over the "true" severity of the issue and what not.

Nerd fights aside, how you feel about this bug, will probably largely depend on how you feel about systemd in general.

The following command, when run as any user, will crash systemd:

NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

After running this command, PID 1 is hung in the pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system. The system feels generally unstable (e.g. ssh and su hang for 30 seconds since systemd is now integrated with the login system). All of this can be caused by a command that's short enough to fit in a Tweet.

Edit (2016-09-28 21:34): Some people can only reproduce if they wrap the command in a while true loop. Yay non-determinism!


Original Submission

Related Stories

Modern Versions of systemd Can Cause an Unmount Storm During Shutdowns 102 comments

System adminsitrator Chris Siebenmann has found Modern versions of systemd can cause an unmount storm during shutdowns:

One of my discoveries about Ubuntu 20.04 is that my test machine can trigger the kernel's out of memory killing during shutdown. My test virtual machine has 4 GB of RAM and 1 GB of swap, but it also has 347 NFS[*] mounts, and after some investigation, what appears to be happening is that in the 20.04 version of systemd (systemd 245 plus whatever changes Ubuntu has made), systemd now seems to try to run umount for all of those filesystems all at once (which also starts a umount.nfs process for each one). On 20.04, this is apparently enough to OOM[**] my test machine.

[...] Unfortunately, so far I haven't found a way to control this in systemd. There appears to be no way to set limits on how many unmounts systemd will try to do at once (or in general how many units it will try to stop at once, even if that requires running programs). Nor can we readily modify the mount units, because all of our NFS mounts are done through shell scripts by directly calling mount; they don't exist in /etc/fstab or as actual .mount units.

[*] NFS: Network File System
[**] OOM Out of memory.

We've been here before and there is certainly more where that came from.

Previously:
(2020) Linux Home Directory Management is About to Undergo Major Change
(2019) System Down: A systemd-journald Exploit
(2017) Savaged by Systemd
(2017) Linux systemd Gives Root Privileges to Invalid Usernames
(2016) Systemd Crashing Bug
(2015) tmux Coders Asked to Add Special Code for systemd
(2016) SystemD Mounts EFI pseudo-fs RW, Facilitates Permanently Bricking Laptops, Closes Bug Invalid
(2015) A Technical Critique of Systemd
(2014) Devuan Developers Can Be Reached Via vua@debianfork.org
(2014) Systemd-resolved Subject to Cache Poisoning


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: -1, Troll) by Anonymous Coward on Wednesday October 05 2016, @12:51AM

    by Anonymous Coward on Wednesday October 05 2016, @12:51AM (#410417)

    No! Linux has always been fucking perfect! How dare anyone code anything new on Linux perfection!!

    Linux! Linux! Linux! Linux!

    Chant it with me!

    Linux! Linux! Linux! Linux! Linux! Linux!

    • (Score: 3, Funny) by Anonymous Coward on Wednesday October 05 2016, @01:04AM

      by Anonymous Coward on Wednesday October 05 2016, @01:04AM (#410420)


      $ NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
      bash: systemd-notify: command not found

      *yawns*~ Smug Gentoo user here.

      • (Score: 0) by Anonymous Coward on Wednesday October 05 2016, @01:07AM

        by Anonymous Coward on Wednesday October 05 2016, @01:07AM (#410423)
        $ NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
        -bash: systemd-notify: command not found

        Slackware user here - same result, no problems.

        • (Score: -1, Redundant) by Anonymous Coward on Wednesday October 05 2016, @01:32AM

          by Anonymous Coward on Wednesday October 05 2016, @01:32AM (#410435)

          NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

          N
          o

          p
          r
          o
          b
          l
          e
          m

          h
          e
          r
          e
          .

          W
          T
          H
          ?

        • (Score: 2) by NotSanguine on Wednesday October 05 2016, @02:37AM

          by NotSanguine (285) <reversethis-{grO ... a} {eniugnaStoN}> on Wednesday October 05 2016, @02:37AM (#410469) Homepage Journal

          I was able to reproduce the bug on Fedora Core 21 (kernel 4.1.8-100).

          After entering "NOTIFY_SOCKET=/run/systemd/notify systemd-notify "" as an unprivileged user, systemd became unresponsive in starting/stopping/restarting services as root.

          However, I was able to execute 'systemctl daemon-reload' as root, and voila! systemd is responsive again.

          As such, it seems that this is less of an issue than it might be, since a reboot isn't required to recover from the bug.

          It's still ridiculous that systemd is vulnerable in this way, any code that is as central as systemd now is, should be much more careful in parsing/validating input.

          --
          No, no, you're not thinking; you're just being logical. --Niels Bohr
          • (Score: 0) by Anonymous Coward on Sunday October 09 2016, @01:41PM

            by Anonymous Coward on Sunday October 09 2016, @01:41PM (#412056)

            Was the root session open already?

      • (Score: 2, Funny) by Anonymous Coward on Wednesday October 05 2016, @01:48AM

        by Anonymous Coward on Wednesday October 05 2016, @01:48AM (#410443)

        *yawns*~ Smug Gentoo user here.

        I didn't have any problems either.
        ~ oblivious Windows user here.

    • (Score: -1, Troll) by Anonymous Coward on Wednesday October 05 2016, @01:06AM

      by Anonymous Coward on Wednesday October 05 2016, @01:06AM (#410422)

      Why not modded down yet, rabid Linux dweebs?

      Here's your proof, Linux was shit:

      https://ftp.kernel.org/pub/linux/kernel/v2.1/WARNING-2.1.44 [kernel.org]

      WARNING: 2.1.44 is extremely unstable and can cause filesystem
      corruption! Please test only on systems where you can tolerate data
      loss!

      Corruption? Data loss? CAUSED BY LINUX?????????

      • (Score: -1, Redundant) by Anonymous Coward on Wednesday October 05 2016, @01:14AM

        by Anonymous Coward on Wednesday October 05 2016, @01:14AM (#410428)

        https://ftp.kernel.org/pub/linux/kernel/v2.1/WARNING-2.1.44 [kernel.org]

        NET::ERR_CERT_COMMON_NAME_INVALID

        Lying troll is a liar.

        • (Score: 3, Interesting) by butthurt on Wednesday October 05 2016, @01:49AM

          by butthurt (6141) on Wednesday October 05 2016, @01:49AM (#410445) Journal

          I wish we could leave the SSL certificate aside. The troll's quote is accurate. If you think kernel.org has been hijacked (which itself would be newsworthy) you can compare the page to an archived copy on archive.org:

          https://web.archive.org/web/20000902093410/http://ftp.kernel.org/pub/linux/kernel/v2.1/WARNING-2.1.44 [archive.org]

          Here's a bug report:

          http://lkml.iu.edu/hypermail/linux/kernel/9707.1/0068.html [iu.edu]

          Note that this was in 1997. At that time, the Linux kernel was, if I'm not mistaken, developed without the use of a source code management system (SCMS) and perhaps for that reason, without branches. New features were added during an "unstable" development period, during which the 2.1 versions (for example) were released, then bugs were corrected during a "stable" development period, during which the 2.0 and later the 2.2 versions (for example) were released. At any one time, only one version was under development. Like other 2.1.x versions, Linux 2.1.44 was never intended for serious use; its purpose was for the introduction and testing of new features. Versions 2.0, 1.8, 1.6 etc. (with even-numbered minor version numbers) were intended for production use.

          Now, about systemd. This, according to freedesktop.org, is how development of systemd proceeds:

          The upstream systemd git repo only contains the main systemd branch that progresses at a quick pace, continuously bringing both bugfixes and new features. Distributions usually prefer basing their releases on stabilized versions branched off from this, that receive the bugfixes but not the features.

          -- https://www.freedesktop.org/wiki/Software/systemd/Backports/ [freedesktop.org]

          So an SCMS is being used, which is nice, but (just going by this quote) the task of producing thoroughly-tested stable versions of the software seemingly is left up to distributors. If that's true, it suggests to me that stability isn't yet the highest priority in systemd's development. Yet the functions systemd performs are crucial, and some distributors have chosen to include it in the stable releases of their Linux-based operating systems.

          • (Score: 0, Insightful) by Anonymous Coward on Wednesday October 05 2016, @01:55AM

            by Anonymous Coward on Wednesday October 05 2016, @01:55AM (#410448)

            Oh wow! Self referential trolling really does work.

            • (Score: -1, Troll) by Anonymous Coward on Wednesday October 05 2016, @01:57AM

              by Anonymous Coward on Wednesday October 05 2016, @01:57AM (#410450)

              Boo hoo. Stop calling me gullible Gulliver.

          • (Score: 2) by opinionated_science on Wednesday October 05 2016, @02:58PM

            by opinionated_science (4031) on Wednesday October 05 2016, @02:58PM (#410626)

            I will repeat - debian jessie does not have this bug. They are running an older/stable/patched version (2.15).

            Perhaps the issue with systemd is that different environments (kernel/libraries) etc has caused "bug boundaries"

            If you watched the last LP talk, there are attempts to greatly reduce this problem with the "portable" systemd interface.

            uptime 10:30am up 468 days 11:59, 1 user, load average: 0.43, 0.30, 0.35

            Show me a windows or Mac with uptime like that....

            • (Score: 0) by Anonymous Coward on Wednesday October 05 2016, @03:43PM

              by Anonymous Coward on Wednesday October 05 2016, @03:43PM (#410653)

              So you didn't install kernel patches for over a year?

              Anyway, such uptime should be easy to achieve (not tested): Start BIOS, set time to past, boot OS, set time to correct value (or let NTP do that).

            • (Score: 2) by butthurt on Thursday October 06 2016, @01:05AM

              by butthurt (6141) on Thursday October 06 2016, @01:05AM (#410900) Journal

              > I will repeat - debian jessie does not have this bug. They are running an older/stable/patched version (2.15).

              Good for Debian, but does the systemd project attempt to make stable releases so that all distributors who care about such things?

              > Perhaps the issue with systemd is that different environments (kernel/libraries) etc has caused "bug boundaries"

              I don't understand the term "bug boundaries".

              > If you watched the last LP talk, there are attempts to greatly reduce this problem with the "portable" systemd interface.

              I must admit, I haven't watched even one of his talks. Did you go to the systemd conference?

              > [...] up 468 days 11:59, 1 user [...]

              I don't suppose that one user is malicious. Is ksplice in use?

            • (Score: 0) by Anonymous Coward on Sunday October 09 2016, @01:38PM

              by Anonymous Coward on Sunday October 09 2016, @01:38PM (#412054)

              Linux ran stable for years even with sysv, big woop...

      • (Score: 3, Informative) by jmorris on Wednesday October 05 2016, @01:16AM

        by jmorris (4844) on Wednesday October 05 2016, @01:16AM (#410430)

        Yo, tard! The 2.1 series was unstable by design. 2.0, 2.2, 2.4 and 2.6 were stable, 2.1, 2.3, 2.5 the unstable branches. These days there isn't a need for an unstable tree because most of the low level stuff is pretty much in a final state, changing only slowly. Now we have the main branch and an LTS branch since the need is simply for kernel trees that will receive security patches for a long enough time to make them suitable for real world deployment.

        • (Score: -1, Flamebait) by Anonymous Coward on Wednesday October 05 2016, @01:22AM

          by Anonymous Coward on Wednesday October 05 2016, @01:22AM (#410432)

          These days there isn't a need for an unstable tree because most of the low level stuff is pretty much in a final state, changing only slowly.

          Hey, fuckwit! That's the point! Linux is old mature software! Systemd is still new and immature! This story is sensationalist garbage!

          • (Score: 2) by Bot on Wednesday October 05 2016, @01:48AM

            by Bot (3902) on Wednesday October 05 2016, @01:48AM (#410444) Journal

            1. you did not ROTFLMAO at the GP epic fail
            2. you admit systemd has no place in any production system

            I either salute a subtle troll, or predict an astroturfer won't get his 50cents from RH.

            --
            Account abandoned.
    • (Score: 4, Touché) by Bot on Wednesday October 05 2016, @01:40AM

      by Bot (3902) on Wednesday October 05 2016, @01:40AM (#410438) Journal

      Yeah bugs.

      Before systemd:

      Do X
      Error Y

      Hm well let's try to reboot
      Do X
      Error Y

      Hm let's try to update
      Do X
      Error Y

      Hm let's try to recompile
      Do X
      Error Y

      Hm let's go to the forums, bts, whatever
      "I do X, i get error Y"
      "me too on arm"
      "do Z"

      Do Z
      Do X
      OK

      On systemd> see windows.

      --
      Account abandoned.
      • (Score: 3, Funny) by Anonymous Coward on Wednesday October 05 2016, @02:48AM

        by Anonymous Coward on Wednesday October 05 2016, @02:48AM (#410475)

        I thought it was:

        Do X
        Error Y

        Hm well let's try to reboot
        Do X
        Error Y

        Hm let's try to update
        Do X
        Error Y

        Hm let's try to recompile
        Do X
        Error Y

        Hm let's go to the forums, bts, whatever
        "I do X, i get error Y"
        DIAF TROLL how dare you criticize SYSTEMD?!?!?! HAHA LOOK AT THE N00B THROWING A TANTRUM!!!

  • (Score: 2) by opinionated_science on Wednesday October 05 2016, @12:57AM

    by opinionated_science (4031) on Wednesday October 05 2016, @12:57AM (#410419)

    I checked blog - not for jessie (debian version). I'm on systemd 2.15.

  • (Score: 2, Informative) by Anonymous Coward on Wednesday October 05 2016, @01:16AM

    by Anonymous Coward on Wednesday October 05 2016, @01:16AM (#410429)

    The bug only happens if assert() calls are still in the code. They should not be in a production system, so the problem is really with distros that didn't build correctly. This would be a non-story if it didn't involve systemd.

    • (Score: 0) by Anonymous Coward on Wednesday October 05 2016, @01:28AM

      by Anonymous Coward on Wednesday October 05 2016, @01:28AM (#410434)

      Don't you just hate it when newbs litter their code with assert? Always reminds me of this.

      LAFORGE: Hey! We've got a red light on the second intake valve.
      COCHRANE: Ignore it. We'll be fine.

      • (Score: 3, Touché) by driverless on Wednesday October 05 2016, @09:23AM

        by driverless (4770) on Wednesday October 05 2016, @09:23AM (#410534)

        Worse is:

        Main Circulating Pumps are shut down and control rods fully withdrawn. SKALA control system is signalling emergency.
        Ignore comrade, is Russian reactor, will not melt down.

      • (Score: 2) by HiThere on Wednesday October 05 2016, @06:24PM

        by HiThere (866) on Wednesday October 05 2016, @06:24PM (#410752) Journal

        Lots of asserts in the code should not be a problem (except it might impede reading the code). Asserts should catch errors during development, and be removed from the release code by the compiler.

        FWIW, I often have lots of asserts in areas of code that I think should never be reached. If they are reached, it's a mistake, and needs to be fixed. I only remove them if it impedes reading the code.

        This assert appears to signal in invalid assumption when the code was being written. Perhaps it shouldn't be a problem, but that's not the way to bet. What this problem appears to clearly signal is improper testing.

        P.S.: systemd is overly large an complex. You need to expect this kind of problem to not only happen once, but to keep happening. When code is simple it's relatively easy to test all execution pathways. As it gets larger and more complex, this gets harder. I consider the design of systemd to be a gross error if you want stable and bug free code. That said, it's never caused me a problem yet that I haven't eventually been able to recover from, if only by reversion.

        --
        Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
    • (Score: 2) by sjames on Wednesday October 05 2016, @02:01AM

      by sjames (2882) on Wednesday October 05 2016, @02:01AM (#410454) Journal

      The assert covers unsanitized input, WTF?!?

      • (Score: 0) by Anonymous Coward on Sunday October 09 2016, @01:24PM

        by Anonymous Coward on Sunday October 09 2016, @01:24PM (#412047)

        And it gets better...

        https://news.ycombinator.com/item?id=12655048 [ycombinator.com]

        Not only does Poettering misrepresent what caused the issue, the git log shows he was the one that did the alterations that lead to the issue.

  • (Score: 5, Insightful) by jmorris on Wednesday October 05 2016, @01:27AM

    by jmorris (4844) on Wednesday October 05 2016, @01:27AM (#410433)

    It isn't that this bug won't be swiftly squashed. It will be, and the distros will push updates quickly. The problem is that systemd, like all of the Red Hat / Pottering OS "Alien Tech" is built around the same defective ideas that have meant Windows NT / XP / 7 / 8 / 10 have been and probably always be roach motels. Big monoliths are inherently unstable because they are too big to know.

    When nobody knows all of the details of how a system works they have three choices.

    1. Muddle through as best as one can because ya got a job to do. a few years accretion of the cruft that sort of thing brings on is why Windows can never be fixed, only tossed and rewritten. In exactly the same way as the open source world tried for a bit to whip the original source dump of Netscape into shape only to mostly toss it and rewrite something simpler and without the years of accumulated cruft. Systemd is on this course.

    2. Admit defeat and don't touch it. Meaning you use a distro that doesn't use any of the "Alien Tech" and get on with a happier life.

    3. Spend large amounts of time and effort to understand it... if you are capable and the docs exist. This cuts the userbase down to nothing so never actually happens in the real world. People have better things to do with their life, except for the elect few being paid by RedHat to develop this crap. Or you can buy a service contract... and pay Red Hat to know how it works. Which is what they are trying to achieve. But it will probably fail, Microsoft too tried this tactic and very quickly found they couldn't understand it either.

    • (Score: 5, Interesting) by TheGratefulNet on Wednesday October 05 2016, @01:38AM

      by TheGratefulNet (659) on Wednesday October 05 2016, @01:38AM (#410437)

      history will likely show that the intro of systemd was the downfall of linux.

      I hope we recover and undo systemd at some future date. why it was pushed out to SO many distros (redhat, yes, I understand; debian based ones, though, I have no idea why that ended up being voted in) - its just a damned shame that its not limited to ONE 'test' distro. let the testers have their fun, but on PRODUCTION, wow, just wow.

      it really does show that the 'kids are in control' and they seem to have such attitudes that they KNOW better than us greyhairs. sigh....

      well, there is the BSD distros. I guess we can think about switching over. I was once a big freebsd guy, myself, back when linux was still going stable/unstable back and forth. then, a few years ago, it got stable enough that I dumped all my bsd systems. at this point, I may have to think about going back; but linux has taken over the embedded world and no one (that I know of) runs bsd on their embedded hardware anymore. all the jobs I've seen and have interviewed for have been linux.

      --
      "It is now safe to switch off your computer."
      • (Score: -1, Flamebait) by Anonymous Coward on Wednesday October 05 2016, @01:48AM

        by Anonymous Coward on Wednesday October 05 2016, @01:48AM (#410442)

        history will likely show that the intro of systemd was the downfall of linux

        And you Linux scum will deserve it, because asshole Linux followers were the downfall of GNU. It is fitting that systemd will be the downfall of you. Bye bye fuckers.

      • (Score: 1, Informative) by Anonymous Coward on Wednesday October 05 2016, @12:01PM

        by Anonymous Coward on Wednesday October 05 2016, @12:01PM (#410548)

        The standard linux is still free of it. http://slackware.com/ [slackware.com]

        • (Score: 0) by Anonymous Coward on Sunday October 09 2016, @01:27PM

          by Anonymous Coward on Sunday October 09 2016, @01:27PM (#412049)

          For now.

          One may wonder if they will adopt systemd or drop every big DE from their repository when time comes...

      • (Score: 2) by VLM on Wednesday October 05 2016, @12:52PM

        by VLM (445) on Wednesday October 05 2016, @12:52PM (#410561)

        linux has taken over the embedded world

        How long will that last in a world of Gnome boot-loading windows architecture?

        Look smaller. I have an olimex dev board on my desk at home to play with, its just an overgrown pic32, and in my infinite spare time I'm going to retro-BSD it. The point being that embedded as in "I velcro'd mah tablet onto mah refrigerator" is going all linux-y but coming up from the bottom the low performance PIC in your next toaster might very well be running *BSD.

        I mean if you want a unix like internet grade OS, thats not linux anymore, but the good news is even lower end microcontrollers are getting powerful enough to run real unix, and a real unix is probably a good OS for "internet of crappy things" and all those buzzwords. You want something that works in a toaster, not something that finally solves automounting floppy disks on gnome desktop (in 2016) at enormous reliability and security cost.

      • (Score: 0) by Anonymous Coward on Wednesday October 05 2016, @02:04PM

        by Anonymous Coward on Wednesday October 05 2016, @02:04PM (#410592)

        Try antiX Linux? Proudly (almost!! damn thing is like aids to flush out) systemd free!

      • (Score: 2) by Kromagv0 on Wednesday October 05 2016, @02:31PM

        by Kromagv0 (1825) on Wednesday October 05 2016, @02:31PM (#410613) Homepage

        Well there is always Slackware. if they go to systemd you know it will be here for the long haul.

        --
        T-Shirts and bumper stickers [zazzle.com] to offend someone
      • (Score: 0) by Anonymous Coward on Wednesday October 05 2016, @03:17PM

        by Anonymous Coward on Wednesday October 05 2016, @03:17PM (#410637)

        iOS is based on FreeBSD like MacOS is, so at least one embedded device running *BSD

      • (Score: 2) by hopp on Wednesday October 05 2016, @07:06PM

        by hopp (2833) on Wednesday October 05 2016, @07:06PM (#410771)

        It was the inclusion of systemd which made me take another look at FreeBSD for our systems. We left FreeBSD when the whole 4-5 upgrade debacle happened and happily returned to FreeBSD when systemd became the standard. bhyve is actually a pretty nice way to layer vm over the zfs and upgrades and auditing are a breeze.

        We're a tiny shop so we matter to no one and we may go back to linux some day but for now BSD is our best option.

    • (Score: -1, Disagree) by Anonymous Coward on Wednesday October 05 2016, @01:41AM

      by Anonymous Coward on Wednesday October 05 2016, @01:41AM (#410439)

      Windows NT / XP / 7 / 8 / 10 have been and probably always be roach motels. Big monoliths are inherently unstable because they are too big to know.

      Oh dear holy shit, the blatant ignorance burns the eyes. You know the Linux kernel is monolithic, right? Are you aware of the debate between Torvalds and Tanenbaum regarding microkernel design? You know NT is a microkernel, right?

      You know what, fuck you. Fuck you and fuck every Linux user who is as willfully fucking ignorant and biased as you. Go fuck yourselves, all of you. You're all complete shit. Burn in hell.

      • (Score: 3, Informative) by butthurt on Wednesday October 05 2016, @02:03AM

        by butthurt (6141) on Wednesday October 05 2016, @02:03AM (#410456) Journal

        > You know NT is a microkernel, right?

        That was abandoned with Windows NT 4.0:

        The major architectural change in this version of Windows NT is the move of the Window Manager, Graphics Device Interface (GDI), and higher-level device drivers from the Win32 environment subsystem into the Windows NT Executive as an executive service.
        [...]
        The most significant aspect of this change is that graphics services, which used to run in user mode like applications, now run in kernel mode like most of the operating system. The idea behind kernel mode and its alternative, user mode, is to separate applications from the operating system. Applications run in user mode; operating systems run in kernel mode.

        Kernel mode is a highly privileged mode of operation where the code has direct access to all memory, including the address spaces of all user-mode processes and applications, and to hardware.

        -- https://www.microsoft.com/resources/documentation/windowsnt/4/workstation/reskit/en-us/archi.mspx [microsoft.com]

      • (Score: 2) by Dunbal on Wednesday October 05 2016, @02:32AM

        by Dunbal (3515) on Wednesday October 05 2016, @02:32AM (#410467)

        No seriously - tell us how you really feel, AC.

      • (Score: 2, Informative) by Arik on Wednesday October 05 2016, @06:19AM

        by Arik (4543) on Wednesday October 05 2016, @06:19AM (#410513) Journal
        Neither NT nor Linux are pure types. NT started with a microkernel and over time evolved into a monolithic kernel, while Linux has done the opposite.

        And that's all completely beside the point you were replying to. He wasn't talking about a monolithic kernel necessarily. He was talking about monolithic system design. Systemd has not yet had much effect on the kernel at all, but it's still a giant monolithic pile of poo no matter what kernel it runs under.
        --
        If laughter is the best medicine, who are the best doctors?
  • (Score: 2, Touché) by Anonymous Coward on Wednesday October 05 2016, @01:36AM

    by Anonymous Coward on Wednesday October 05 2016, @01:36AM (#410436)

    uncovered a bug which will either crash or make systemd unstable

    You mean turning the power on? :^)

    • (Score: 2) by MostCynical on Wednesday October 05 2016, @02:05AM

      by MostCynical (2589) on Wednesday October 05 2016, @02:05AM (#410457) Journal

      Not a bug -a feature!
      Everyone knows Linux users *want* to spend hours and hours compiling and bug fixing and never showering and never leaving the basement!

      --
      "I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
    • (Score: 2) by Dunbal on Wednesday October 05 2016, @02:34AM

      by Dunbal (3515) on Wednesday October 05 2016, @02:34AM (#410468)

      Nah, you're good. But if you let the computer run anything past the BIOS, you're on your own.

      • (Score: 2) by maxwell demon on Wednesday October 05 2016, @06:51AM

        by maxwell demon (1608) Subscriber Badge on Wednesday October 05 2016, @06:51AM (#410516) Journal

        I think Grub is still independent of systemd.

        --
        The Tao of math: The numbers you can count are not the real numbers.
        • (Score: 3, Informative) by Dunbal on Wednesday October 05 2016, @11:03AM

          by Dunbal (3515) on Wednesday October 05 2016, @11:03AM (#410542)

          For now.

  • (Score: 4, Funny) by Bot on Wednesday October 05 2016, @02:03AM

    by Bot (3902) on Wednesday October 05 2016, @02:03AM (#410455) Journal

    As you may remember I am the substitute for the long gone systemd troll.

    So, my insights.

    1. become like windows, behave like windows.
    I DID WARN YOU. How did I know? Well, I did not switch off the brain.

    2. a problem in systemd? good thing we gave systemd the task of managing cgroups so the damage is contained. Right?

    2. systemd devs have already slapped a wontfix on it, suggest patching Bash who let users arbitrarily mess with environmental vars.

    3. My counterd is not working as usual.

    --
    Account abandoned.
    • (Score: 5, Funny) by Bot on Wednesday October 05 2016, @02:05AM

      by Bot (3902) on Wednesday October 05 2016, @02:05AM (#410458) Journal

      4. What about windows and systemd?
      "History repeats itself, first as tragedy, second as farce." - Karl Marx

      --
      Account abandoned.
    • (Score: 2) by VLM on Wednesday October 05 2016, @12:33PM

      by VLM (445) on Wednesday October 05 2016, @12:33PM (#410557)

      3. My counterd is not working as usual.

      They must have embedded your counter in systemd, no wonder.

      Somewhat more comically

      systemd devs have already slapped a wontfix on it, suggest patching Bash who let users arbitrarily mess with environmental vars.

      The more likely long term outcome is a "standard" systemdsh which will be a port of powershell or plain old cmd.exe to linux, complete with \\\ for directories and everything. Oh and drive letter support.

      • (Score: 3, Funny) by Bot on Wednesday October 05 2016, @02:21PM

        by Bot (3902) on Wednesday October 05 2016, @02:21PM (#410604) Journal

        DON'T GIVE THEM IDEAS!

        --
        Account abandoned.
      • (Score: 2) by DECbot on Wednesday October 05 2016, @11:19PM

        by DECbot (832) on Wednesday October 05 2016, @11:19PM (#410873) Journal

        With my suggestion [soylentnews.org] of inputd and outputd, there would be no need to create a new shell, not that a new shell isn't in the scope of systemd, because with inputd and outputd you can sanitize all standard input and output from one application before allowing the shell to pass it to the next process. With inputd and outputd, you can set a meta environment that supersedes the shell environment and be persistent between shells and processes. Thus you can set "aliases" that will "translate" valid powershell script into bash or even bash script to powershell and provide support of drive letters and whatnot. That is the power of inputd and the myriad of asinine arguments you can pass to inputd. You should even be able to assert() null strings and get a valid response when passing the proper undocumented, ever-changing argument string to inputd! I imagine you could even use inputd to modify the inputs to inputd while passing arguments to inputd. I can see the turtles all the way down!

        Once systemd firmly requires inputd and outputd and those have royally screwed up the regular /bin/sh environment, then it will be time for the systemd team to come out with /bin/sh_d, which will be nothing more than a simlink to /bin/registryd or the like.

        --
        cats~$ sudo chown -R us /home/base
  • (Score: 4, Interesting) by darkfeline on Wednesday October 05 2016, @02:14AM

    by darkfeline (1030) on Wednesday October 05 2016, @02:14AM (#410464) Homepage

    Here's my FUD-free opinion on the subject: systemd doesn't matter

    Recently, I've come to the conclusion that FreeBSD is the right OS for any standard server machine. It has a clean, integrated core, and you can install whatever you need on top of it (Apache, etc.).

    For servers, Linux really only wins if you need something custom hacked together, in which case systemd doesn't matter. If you dislike it, use a different init, you're hacking together your OS, after all.

    For a desktop machine, I'm more than willing to deal with systemd's shortcomings to benefit from what it offers (and if you think systemd offers absolutely zero benefits over sysvinit/initscripts, flaws notwithstanding, you are blinded by your rage, my friend), but there are still many options, not least of which is, make your own distro or distro fork. FOSS has never been about getting a free lunch, it's about being able to work for your lunch without getting cockblocked by lack of source code or copyright/patent law.

    --
    Join the SDF Public Access UNIX System today!
    • (Score: 0) by Anonymous Coward on Wednesday October 05 2016, @03:50AM

      by Anonymous Coward on Wednesday October 05 2016, @03:50AM (#410491)
    • (Score: 3, Informative) by Arik on Wednesday October 05 2016, @07:22AM

      by Arik (4543) on Wednesday October 05 2016, @07:22AM (#410521) Journal
      Hey if you like FreeBSD then use it, but when you say 'Linux' and equate it with RedHat you're missing a good deal. Slackware ain't dead.
      --
      If laughter is the best medicine, who are the best doctors?
      • (Score: 2) by darkfeline on Wednesday October 05 2016, @05:26PM

        by darkfeline (1030) on Wednesday October 05 2016, @05:26PM (#410726) Homepage

        I exclusively use Arch Linux and Debian on the Linux side, my dear friend Arik. Neither of which are RedHat nor are they systemd exclusive, regardless of whether they ship it by default now. As far as I'm concerned, Slackware is just a lukewarm LFS.

        --
        Join the SDF Public Access UNIX System today!
    • (Score: 2) by VLM on Wednesday October 05 2016, @12:42PM

      by VLM (445) on Wednesday October 05 2016, @12:42PM (#410559)

      Let me fix your typo

      I've come to the conclusion that FreeBSD is the right OS for any machine

      Great minds must think alike...

      Back when I was using "not quite unix" I was like, eh I got LVM and MD, what do I need ZFS for, but now I love ZFS...

      I've come to enjoy /usr/ports although its an acquired taste. Its generally more up to date than linux solutions and actually works. You really can install something obese and ridiculous like Jenkins from ports and it just works. Ditto slurm and its friends munge etc. Stuff just works.

      PF is like tea vs coffee, if you go in thinking its just swap one keyword for another you'll have a rough time, but once you're comfortable with the differing architecture its pretty smooth.

      • (Score: 2) by darkfeline on Wednesday October 05 2016, @05:32PM

        by darkfeline (1030) on Wednesday October 05 2016, @05:32PM (#410729) Homepage

        No, FreeBSD is not the right OS for my personal machine. I like being able to modify my kernel/core userland freely, and the BSD model obstructs that. Personal OS preferences are, well, personal, but for servers there are a few objective rights and wrongs.

        Nothing wrong with BSD, I just like breaking things on my own time.

        --
        Join the SDF Public Access UNIX System today!
        • (Score: 2) by VLM on Wednesday October 05 2016, @05:55PM

          by VLM (445) on Wednesday October 05 2016, @05:55PM (#410743)

          and the BSD model obstructs that

          How does that even work?

          Obviously not a legal thing since you're all "my machine". You can always do anything you want on your machine. Redistribution, well thats where things get interesting with both BSD and GPL and several other licenses.

          I'm guessing you're implying that if you make massive changes to the base/core then "freebsd-update" can be a bit brutal about setting things back the way they should be. Of course if you change things enough (like massive changes to file system hierarchy) then its not really freebsd anymore such that you can't expect to use freebsd's update in the future. But it doesn't really stop you from changing, just stop you from applying fresh freebsd on top of no longer freebsd. Like if as an experiment you implemented apple OSX file system hierarchy on freebsd, that might get a bit weird and freebsd-update would likely get wound up about it.

          Oh maybe if you disagree fundamentally with the way something is done in /usr/ports and unlike the million dials currently in /usr/ports it can't just be tweaked as an option, it can't be fixed inside /usr/ports. I can't imagine what because /usr/ports is like gentoo on speed or something. But assuming "it" exists although I can't imagine what... You could compile as a package and use pkgng. You can add your personal repo for other machines to /usr/local/etc/pkg.conf just like messing with /etc/apt/sources.list on linux. Or I suppose just not use pkgng or ports and install software by hand like we used to in the early 90s. I don't really miss those days but it'll work. I know I should be deploying locally made software as packages like I used to on linux, but build automation and ansible and puppet type systems make it easy to manually automatically deploy...

  • (Score: 3, Insightful) by Anonymous Coward on Wednesday October 05 2016, @03:48AM

    by Anonymous Coward on Wednesday October 05 2016, @03:48AM (#410490)

    systemd developers are fucking incompetent as fuck.

    this is proof they don't know what the fuck they are doing, and focus on shiny features.

    Yeah, so putting xinetd, cron, automount, and fuck knows what else, into one fucking package, has now been proven, beyond any doubt, to be a fucking irrational idea from a fucking massively incompetent programmer, who isn't actually a linux user.

    OH NO ANON YOU ARE WRONG SYSTEMD IS MODULAR!!!

    No, it isn't, so fuck off, you fucking deceptive, lieing, cunt. Proof: systemd --user.

    Lennart and all the systemd people, dbus people, network manager people, all need to catch one plane somewhere. Pity it wasn't MH370.

    • (Score: 0) by Anonymous Coward on Sunday October 09 2016, @01:32PM

      by Anonymous Coward on Sunday October 09 2016, @01:32PM (#412050)

      Most of them seem to have come "down" from the DE (Gnome in particular) and web dev realms, rather than "up" from the kernel realm.

      Meaning that they are unlikely to be fully aware of what unix has to offer already, but well versed in the "point and grunt" side of Windows and OSX.

  • (Score: 0) by Anonymous Coward on Wednesday October 05 2016, @03:56AM

    by Anonymous Coward on Wednesday October 05 2016, @03:56AM (#410492)

    I'd rather have a bug with Linux that I know will be fixed soon in an update... than that crapware/spyware/bloatware/BSOD-POS they call Windows.

  • (Score: 3, Touché) by Arik on Wednesday October 05 2016, @06:14AM

    by Arik (4543) on Wednesday October 05 2016, @06:14AM (#410512) Journal
    "What makes it a tantrum? It’s a tantrum when you use a minor security issue as justification to rant about everything remotely related to systemd and insist on radical changes (throwing out systemd) to address what are mostly fixable quibbles — at least the quibbles that were based on facts or good judgment in the first place."

    So that would mean that when you lot used far more minor non-security issues as a justification to wrap up everything remotely related to init (and a lot of stuff that's not) into this systemd thing and shove it down our throats, YOU were throwing a tantrum?

    This is not the first and it won't be the last bug of this type. Those who use systemd are condemned to use systemd. The most cruel of sentences.
    --
    If laughter is the best medicine, who are the best doctors?
    • (Score: 4, Interesting) by zocalo on Wednesday October 05 2016, @06:41AM

      by zocalo (302) on Wednesday October 05 2016, @06:41AM (#410515)

      This is not the first and it won't be the last bug of this type.

      No doubt Poettering will put a bandaid on this one, close the bug and call it a day. Everyone happy (so far as you can be in systemd-land), rejoice. Or not.

      Given that this is a basic input sanitation failure, I think that's pretty much a given that if you are not sanitizing one input, then there's a very good chance that you are not sanitizing others as well. Another thing that's particularly interesting about this is that a user can have a major system level impact which implies there are problems with verifying the way that commands and parameters are passed from userland into the core of the systemd processes running as root as well. Right now, I'd expect a lot of rootkit and exploit developers are going through the code looking for other places where systemd fails to validate inputs and seeing what they can do with them, and it's anyone's guess where that might lead.

      --
      UNIX? They're not even circumcised! Savages!
      • (Score: 5, Funny) by DECbot on Wednesday October 05 2016, @03:14PM

        by DECbot (832) on Wednesday October 05 2016, @03:14PM (#410634) Journal

        You know, I think it would be even better if Poettering instead of patching this bug shows his programming chops by adding a new module to systemd called inputd. Inputd would be responsible for sanitizing all standard input before passing it to the application reading standard input. And when an application reads input from inputd, it can pass a bunch of asinine arguments to inform inputd of what the sanitized input should look like.

        Likewise, we can have an outputd that will sanitize the standard output, so you can turn on all the DEBUG flags, make the kernel spit out garbage, but sanitize the output before you send it over to the logs so no one knows you left the debug flags on.

        --
        cats~$ sudo chown -R us /home/base
        • (Score: 0) by Anonymous Coward on Sunday October 09 2016, @01:35PM

          by Anonymous Coward on Sunday October 09 2016, @01:35PM (#412052)

          They do have a dev involved that was working on a user space tty implementation...

  • (Score: 1) by Slartibartfast on Wednesday October 05 2016, @12:19PM

    by Slartibartfast (5104) on Wednesday October 05 2016, @12:19PM (#410551)

    While I'm not really pro- or anti- systemd, I think it's foolish to say that ANY system stability issue that can easily be triggered by a non-privileged user isn't major. This is right up there with the ol' F00F kernel bug.

    • (Score: 0) by Anonymous Coward on Wednesday October 05 2016, @03:54PM

      by Anonymous Coward on Wednesday October 05 2016, @03:54PM (#410662)

      That F00F bug was not a kernel bug, it was a CPU bug.

  • (Score: 0) by Anonymous Coward on Wednesday October 05 2016, @06:15PM

    by Anonymous Coward on Wednesday October 05 2016, @06:15PM (#410749)

    while it may be true that this bug shouldn't of happened in the first place (idk), from an end user's perspective it was not that big of a deal. i got an email telling me their was a security issue and that i needed to update. then i had to run "pacman -Syu" to fix it. pretty rough. :)