6 ms·

He's referring to the fact that systemd was (is) very controversial when it was announced as a replacement for SystemV init. There were _lots_ of flamewars and

He's referring to the fact that systemd was (is) very controversial when it was announced as a replacement for SystemV init. There were _lots_ of flamewars and hyperbole and when Debian announced they were making systemd their only init, it sparked a fork: http://debianfork.org/ http://debianfork.org/ It seems like a lot of people are calming down about the issue now.. so lets not do all that again

vezzy-fnord 11y ago
I wasn't born yesterday, I know that. In fact, I helped fan the flames by making uselessd, though not out of any sly intent in the least, but research curiosity. My question was more about the GP elaborating why a new system would be something "[no one] wants to go through this again." (I'd characterize systemd as being a sysvinit replacement to be a great misnomer. It's not. It's an entire framework for providing certain low-level userspace daemons, utilities and auxiliaries meant as a common middleware for GNU/Linux distributions. Even systemd-the-PID1 cannot be called a sysvinit replacement in any integrity.)
- esaym 11y ago
  >My question was more about the GP elaborating why a new system would be something "[no one] wants to go through this again." Because the migration was terrible that is why. And I still continue to find stuff I hate about systemd. The latest was just yesterday, while troubleshooting some disk issues I wanted to fsck root before rebooting. Which normally means just remount root as read-only. Tried that and it didn't work, "disk was busy". Jumped into runlevel 1, still disk was busy. Rebooted into rescue mode, remount ro, still disk busy. After googling and digging through lsof, I could see it was systemd processes and journal that was holding onto files and preventing a remount. Tried killing systemd, journald, even kill -9, it just restarts it self and holds the disk. Darn. Did the touch /forcefsck trick, rebooted, yet no fsck. Darn again. More googling later, I see you have pass kernel parameters at boot time to force a fsck, and no, you can't select which FS either, it just does all of them. Rebooted again, fsck is running of course. I just wanted root checked but now it is doing all my terabyte partitions as well. Gave up at this point and just left the machine and hoped for the best.
  - lisivka 11y ago
    I hate it too, but workaround is not too hard: chmod a-x journald && pkill journald of course, it is bad idea to touch damaged FS before fsck.
    - simoncion 11y ago
      Wait. To run an unscheduled fsck of your root fs (and only your root fs), you have to remove the execute bit from a systemd component, kill that component, then remember to reset the bit after you're done? That's nuts.
      - morganvachon 11y ago
        That kind of thing is why I stick with Slackware and OpenBSD for my production systems. systemd has some great ideas, but it has some down right silliness as well, and I personally don't feel it's stable enough for daily use yet.
      - rdtsc 11y ago
        (Just to make sure everyone gets it) It will prevent it from running again. So it is basically a big FU! to systemd. "So you you think you gonna restart yourself? Oh, no you won't"
      - pdkl95 11y ago
        That's nothing - systemd panics (pid1 crash) if you restart dbus, which requires either the Magic SysRq or the reset button.. https://forums.gentoo.org/viewtopic-p-7811550.html#7811550 https://forums.gentoo.org/viewtopic-p-7811550.html#7811550 Pottering was apparently told about this in 2013, when he simply declared it expected behavior because dbus was "rock solid". http://lists.freedesktop.org/archives/systemd-devel/2013-January/008456.html http://lists.freedesktop.org/archives/systemd-devel/2013-Jan... Incidentally, this might be the original reason for kdbus - it's harder to restart the daemon after it becomes a kernel module.
        simoncion 11y ago
- e12e 11y ago
  [ed2: Never mind - the standard setup is to have /run mounted as a tmpfs -- I failed to check that before this song and dance] Which distribution was this? I just tried on my laptop (running Debian 8, fs on top of lvm on top of LUKS), and a simple: telinit 1 # log in on console mount -oro,remount / worked as expected. [ed: Actually just tried forcing an fsck as well, and worked without a hitch. Just remember to "mount -oremount /" before running a "telinit 5" (Nothing really bad happens if not, but the system(d) will be confused if rootfs is mounted read-only).]
  - JdeBP 11y ago
    esaym probably doesn't need people to try and diagnose xyr problem, and this isn't really the best venue to do that. If you want to try this, try at least replicating esaym's setup as described rather than using your own and declaring "works for me!". One way that springs to mind is moving the journal into /var/log and having no separate /var/log volume; which reproduces the described setup of open journal files on the root filesystem. Do that and then try to force an explicit check of the root volume. Of course, knowing that does point to one obvious way to avoid the stated problem: move the journal back into /run again (per the journald.conf manual page) and simply restart journald. No mucking about with permissions required. But that's not the only thing that xe could have tried. emergency mode, for example, is documented as not mounting additional non-API filesystems at all, nor read-write remounting the root volume. See http://freedesktop.org/wiki/Software/systemd/Debugging/#bootingintorescueoremergencytargets http://freedesktop.org/wiki/Software/systemd/Debugging/#boot...
    - e12e 11y ago
      Hm, good catch. I thought I checked to see if /run was mounted before going through the whole exercise, but apparently I didn't (My first test was to "mount -t tmpfs /run" -- to shadow the /run mountpoint -- but I didn't realize this already existed as a tmpfs). [ed: Given that it's not wise to write to a fs of questionable state, editing /etc/systemd/journal.conf is out. So it would appear shadowing the sub-tree in question with a tmpfs mount would be the sanest approach?] [ed2: Just checked that if setting "Storage=persistent" in journald.conf, forcing logging under /var/log (and with /var/log as part of the rootfs) at least here, shadowing /var/log with a tmpfs works, in order to remount rootfs read-only in "runlevel 1" (actually systemctl rescue, when using systemd). Not sure if there's any elegant way to unshadow/unmount /var/log w/o a reboot though.]
UnoriginalGuy 11y ago
I think Linus Torvalds coming out in support of systemd helped a lot (or at least confused the UNIX purists enough to calm them down a little). Linus response from [0]: > I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area. > Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision. > Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys. [0] http://linux.slashdot.org/story/15/06/30/0058243/interviews-linus-torvalds-answers-your-question http://linux.slashdot.org/story/15/06/30/0058243/interviews-...
- simoncion 11y ago
  I'm not sure that Torvalds says that he likes systemd. I read the quote as saying: "I don't dislike systemd, and I think that it is better than traditional init.". Almost anything [0] is better than SysV init. shrug [0] Upstart, OpenRC, daemontools...
  - JdeBP 11y ago
    Strictly speaking, of those three only upstart is actually a replacement for System 5 init. OpenRC and daemontools run under an init, and by and large replace System 5 rc. There are two toolsets (soon to be three) in the daemontools family that provide a replacement for init: nosh and runit. daemontools itself does not, and has had more than a decade of people adapting it to run under init replacements because the vanilla system only targets late 1990s inits, including under upstart as a matter of fact. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/daemontools-family.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/da... * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/inittab-is-history.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/in... * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/system-5-rc-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...

vezzy-fnord 11y ago

I wasn't born yesterday, I know that. In fact, I helped fan the flames by making uselessd, though not out of any sly intent in the least, but research curiosity. My question was more about the GP elaborating why a new system would be something "[no one] wants to go through this again." (I'd characterize systemd as being a sysvinit replacement to be a great misnomer. It's not. It's an entire framework for providing certain low-level userspace daemons, utilities and auxiliaries meant as a common middleware for GNU/Linux distributions. Even systemd-the-PID1 cannot be called a sysvinit replacement in any integrity.)

esaym 11y ago
>My question was more about the GP elaborating why a new system would be something "[no one] wants to go through this again." Because the migration was terrible that is why. And I still continue to find stuff I hate about systemd. The latest was just yesterday, while troubleshooting some disk issues I wanted to fsck root before rebooting. Which normally means just remount root as read-only. Tried that and it didn't work, "disk was busy". Jumped into runlevel 1, still disk was busy. Rebooted into rescue mode, remount ro, still disk busy. After googling and digging through lsof, I could see it was systemd processes and journal that was holding onto files and preventing a remount. Tried killing systemd, journald, even kill -9, it just restarts it self and holds the disk. Darn. Did the touch /forcefsck trick, rebooted, yet no fsck. Darn again. More googling later, I see you have pass kernel parameters at boot time to force a fsck, and no, you can't select which FS either, it just does all of them. Rebooted again, fsck is running of course. I just wanted root checked but now it is doing all my terabyte partitions as well. Gave up at this point and just left the machine and hoped for the best.
- lisivka 11y ago
  I hate it too, but workaround is not too hard: chmod a-x journald && pkill journald of course, it is bad idea to touch damaged FS before fsck.
  - simoncion 11y ago
    Wait. To run an unscheduled fsck of your root fs (and only your root fs), you have to remove the execute bit from a systemd component, kill that component, then remember to reset the bit after you're done? That's nuts.
    - morganvachon 11y ago
      That kind of thing is why I stick with Slackware and OpenBSD for my production systems. systemd has some great ideas, but it has some down right silliness as well, and I personally don't feel it's stable enough for daily use yet.
    - rdtsc 11y ago
      (Just to make sure everyone gets it) It will prevent it from running again. So it is basically a big FU! to systemd. "So you you think you gonna restart yourself? Oh, no you won't"
    - pdkl95 11y ago
      That's nothing - systemd panics (pid1 crash) if you restart dbus, which requires either the Magic SysRq or the reset button.. https://forums.gentoo.org/viewtopic-p-7811550.html#7811550 https://forums.gentoo.org/viewtopic-p-7811550.html#7811550 Pottering was apparently told about this in 2013, when he simply declared it expected behavior because dbus was "rock solid". http://lists.freedesktop.org/archives/systemd-devel/2013-January/008456.html http://lists.freedesktop.org/archives/systemd-devel/2013-Jan... Incidentally, this might be the original reason for kdbus - it's harder to restart the daemon after it becomes a kernel module.
      - simoncion 11y ago
e12e 11y ago
[ed2: Never mind - the standard setup is to have /run mounted as a tmpfs -- I failed to check that before this song and dance] Which distribution was this? I just tried on my laptop (running Debian 8, fs on top of lvm on top of LUKS), and a simple: telinit 1 # log in on console mount -oro,remount / worked as expected. [ed: Actually just tried forcing an fsck as well, and worked without a hitch. Just remember to "mount -oremount /" before running a "telinit 5" (Nothing really bad happens if not, but the system(d) will be confused if rootfs is mounted read-only).]
- JdeBP 11y ago
  esaym probably doesn't need people to try and diagnose xyr problem, and this isn't really the best venue to do that. If you want to try this, try at least replicating esaym's setup as described rather than using your own and declaring "works for me!". One way that springs to mind is moving the journal into /var/log and having no separate /var/log volume; which reproduces the described setup of open journal files on the root filesystem. Do that and then try to force an explicit check of the root volume. Of course, knowing that does point to one obvious way to avoid the stated problem: move the journal back into /run again (per the journald.conf manual page) and simply restart journald. No mucking about with permissions required. But that's not the only thing that xe could have tried. emergency mode, for example, is documented as not mounting additional non-API filesystems at all, nor read-write remounting the root volume. See http://freedesktop.org/wiki/Software/systemd/Debugging/#bootingintorescueoremergencytargets http://freedesktop.org/wiki/Software/systemd/Debugging/#boot...
  - e12e 11y ago
    Hm, good catch. I thought I checked to see if /run was mounted before going through the whole exercise, but apparently I didn't (My first test was to "mount -t tmpfs /run" -- to shadow the /run mountpoint -- but I didn't realize this already existed as a tmpfs). [ed: Given that it's not wise to write to a fs of questionable state, editing /etc/systemd/journal.conf is out. So it would appear shadowing the sub-tree in question with a tmpfs mount would be the sanest approach?] [ed2: Just checked that if setting "Storage=persistent" in journald.conf, forcing logging under /var/log (and with /var/log as part of the rootfs) at least here, shadowing /var/log with a tmpfs works, in order to remount rootfs read-only in "runlevel 1" (actually systemctl rescue, when using systemd). Not sure if there's any elegant way to unshadow/unmount /var/log w/o a reboot though.]

UnoriginalGuy 11y ago

I think Linus Torvalds coming out in support of systemd helped a lot (or at least confused the UNIX purists enough to calm them down a little). Linus response from [0]: > I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area. > Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision. > Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys. [0] http://linux.slashdot.org/story/15/06/30/0058243/interviews-linus-torvalds-answers-your-question http://linux.slashdot.org/story/15/06/30/0058243/interviews-...

simoncion 11y ago
I'm not sure that Torvalds says that he likes systemd. I read the quote as saying: "I don't dislike systemd, and I think that it is better than traditional init.". Almost anything [0] is better than SysV init. shrug [0] Upstart, OpenRC, daemontools...
- JdeBP 11y ago
  Strictly speaking, of those three only upstart is actually a replacement for System 5 init. OpenRC and daemontools run under an init, and by and large replace System 5 rc. There are two toolsets (soon to be three) in the daemontools family that provide a replacement for init: nosh and runit. daemontools itself does not, and has had more than a decade of people adapting it to run under init replacements because the vanilla system only targets late 1990s inits, including under upstart as a matter of fact. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/daemontools-family.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/da... * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/inittab-is-history.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/in... * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/system-5-rc-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...