Systemd Continues Getting Bigger, Almost At 550k Lines Of Code

[FatBSDLoser]

Thank god I've long since dumped Linux and switched my personal and work machines to FreeBSD.

The systemd clusterf*ck is something I am enjoying watching from a safe distance.

Have fun wasting your time compiling broken ports and not having a package manager that fetches what you need quickly and in working order.
Also, enjoy slashing your wrists out of frustration on shell scripts and a crappy flaky init system that completely fucks itself completely over whenever one shell script does work properly. Truely, BSD ports are the real cluster fuck and so is their obsolete init system.

The Linux 'community' is nothing more than an entity that maximizes idiotic decisions. The only reason systemd exists is that the Linux community is unable to come up with anything worse.

The best part of the Linux systemd fiasco is knowing just how hilarious the cries of pain are going to be when it comes time to rip it out. And listening to the shouts of 'who is responsible for this mess???'

No, rather it?s the BSD ?community? no? the BSD cult that?s nothing more than a group of mentally ill assholes which maximizes idiotic decisions.
By the way, I heard BSD is trying to copycat something similar by porting launchd. Looks like you?ll have to leave BSD too. And you should cause is nothing more than a crappy copy of system.

Congrats to the systemd developers, they've managed to come up with something that rivals one of the all time greatest operating system software engineering disasters of all time. The Windows Registry.

Yes, congrats to system because their code is way cleaner and more functional then BSD code. Just compare the two. BSD is a utter mess, horribly bloated and ugly to look at. Systemd code by contrast is clean, correct and so well thought out. The only code that?s cleaner and correct is the Linux kernel.

[Chousuke]

*sigh* You're not reading what I even wrote. I never was supporting sysvinit, I CLEARLY said BSD rc init, Since you're so incapable of distinguishing the two let's get how BSD rc init ACTUALLY runs.

There is no such thing as runlevels in BSD init. On startup and shutdown rc reads the contents of /etc/rc.conf and the appropriate shutdown or startup script. Then, it checks for services that are configured to boot on startup via rc.conf and then goes into the rc.d directories and searches for those. It then starts or stops these services as per the command to power on or off from root. During shutdown, after it ensures all processes called from rc.conf are stopped, it kills any processes not needed for shutdown. This is as compared to the inconsistent directories where sysvinit is stored. In sysvinit it is a truly chaotic mess. But BSD's rc init works fine! And guess what? It could be ported to Linux easily. Combine it with a good process supervisor for event based startup and monitoring and you're good to go.

What is this "good process supervisor"? Systemd is an existing solution, while you propose something that doesn't exist. Do any process supervisors other than systemd it provide access to cgroups, namespacing, containers and and who knows what other features the linux kernel might offer? BSD's rc scripts are marginally better than what we have in linux distros, but why is a system based on shellscripts somehow automatically better than one based on actual declarative configuration files? It's certainly not simpler, given that it's pretty difficult to use kernel interfaces from shell code.

Also my arguments 1 and 3 were similar, but 3 was a sort of catchall conclusion to sum myself up and tie everything together. So no, 1 =/= 3. In addition all shell scripts are is automation and I find that way easier to debug. Then again I'm not your average user.

For those who say leaving init alone and having the process supervisor in a different PID is a bad thing, you all again ignore the principle of attack surface. Its not the size of the process that makes a difference, It's what is doing. The less PID 1 is doing, the better. Because if, let's say the supervisor is in PID 2, and it dies, init can still restart it. If systemd locks up or dies, you have to reboot to control services.

I don't understand this argument about size and attack surface. Every time I see it it sounds like systemd is some gigantic thing that does everything in one process, which is nowhere close to the truth. As far as I know Systemd's PID1 is pretty much as small as it can be. You're just automatically assuming it must be worse than some magical "minimal init" just because it provides more functionality and is therefore prone to crashing and malfunctioning. The *kernel* is larger and much more complicated, and it still manages to work reliably on almost everything it runs on.

It's the same in military theory, if I have a convoy of tanks and I spread them out over a wide area, then air strikes from the opposing force require more resources. systemd is rather closely grouped by comparison and its just not what fault tolerance is about. I also left Linux for other reasons, but this and how it's becoming less unique, more like OSX or Windows in terms of design is pushing it, plus the amount of developing I am doing and seeing the poor choices GNU/Linux has made and how it is harming innovation. It really boils down to Linux going from a decent, well designed UNIX clone into a war machine of the FSF and companies like Red Hat and Canonical. They're pushing it as a Windows drop in replacement which it was never designed for. I use BSD and IRIX mostly these days because I align with their philosophies (I'm aware IRIX is outdated, but hey it works fine still and is still ahead of its time.)

[/QUOTE]

[misc]

What I meant with clear is: Don't make it sound like they all voted for systemd, they weren't they were splitted exactly in half and systemd only was chosen because the head of the technical committee is a systemd proponent. If he would be an Upstart proponent the new init system would be Upstart, simple as that.

And yet, the users did show a clear preference with popcon :

http://qa.debian.org/popcon-graph.php?packages=upstart%2Csystemd-sysv&show_installed=on&want_legend=on&want_ticks=on&from_date=2013-08-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

And yeah, the commitee was split in half, but there is at least 1 upstart coder on the commitee, so I would have been surprised he wouldn't choose his own solution. And even with that, the pro-upstart campwas not able to answer the various questions and the old design bugs :

https://bugs.launchpad.net/upstart/+bug/447654

https://bugs.launchpad.net/upstart/+bug/406397

[misc]

This has been discussed in many systemd threads before - systemd tries to re-exec itself if it crashes, but re-exec is not 100% reliable. The kernel is the same, there is no "if systemd" hack there.

Which in the context of the original question (why would service/cgroup manager in pid 2 be better) does not change things. Pid 2 failing to re-exec does not kill the world; pid 1 failing to re-exec does.

In fact, systemd do not try to reexec on crash. Systemd loop on itself to avoid panicing the kernel, see install_crash_handler in src/core/main.c
And the reexec is reliable, as this is done on every boot to be able to unmount the initrd initial root.

Regarding the suggestion of having a PID 2, that's cute but requires more complexity in practice to avoid race conditions. Since PID 1 is the new owner of orphaned process, we need to watch over those process. And when one die, we need to do something, like saying the service is down. Of course, the problem is that this data ( ie, the matching between service and PID ) is in another process, so we need to communicate that to the process PID 2. So, a naive approach is that we send the signal and the PID over some specific socket, serialized so PID 2 can handle the case. That surely work fine on paper, but now, what happen if the PID is reused ? (If someone use PID randomisation and there is lots of process creation, this could happen sooner or later. In fact, without PID randomisation, it could happen. So now, we have a list of PID in PID2, and we receive a message saying "this process got killed", and we just have a PID. Except that we do not know when the PID was valid. So PID 2 receive a message with a PID, and cannot be sure that the PID in the list is the one that correspond. If there is no process with this PID, fine, that mean there is a service that died, and we can find which one it was. If not, then we need to find which one died.

So usually, that's quite easy, the surviving process can be identified, it is in a cgroup and you can get the service, so the other is the one that died. Now, what if 2 process died by reusing a PID, and didn't died in the same way ? what happen if one stopped because it was shortlived, and the 2nd one crashed ?

Now, you have a issue, because you cannot know which process is which. And it does matter, because that's the difference between failed and work as intended. So I am sure someone will suggest to add a timestamp. But due to the asynchronous nature of signals ( and especially since you need to do a call to waitid to get the information required ), you know have yet another race condition.

People suggested to use PR_SET_CHILD_SUBREAPER. Again, this work on paper, but what about when PID 2 crash ? ( becuase, if people accuse "PID 1 is to important to crash", we can also see what happen in the same case with the so called PID 2 ). All the processes are reparented to PID 1. So we are back on square 1, with added complexity.

And even if someone fix that, you just managed to go from "PID 1 just run PID 2" to "PID 1 run PID 2 and serve as a proxy for signal received". You can also add "PID 1 need to supervise PID 2". You didn't touched the way you would communicate safely between PID 1 and PID 2 ( and in both direction, since PID 2 also need to tell to PID 1 to shutdown ). You didn't touch on the need of restarting PID 1 and PID 2 in the initrd to be able to unmount it ( ie, why now you would need to reexec PID 1 and maybe PID 2, so twice the complexity ).

And the whole PID 2 idea doesn't even help on separating privileges, since now, everything got moved to PID 2 ( ie, it run as root, it can go in any selinux domain per design, and it listen on all interface of the current design, and add its own communication channel with PID 1 ). And you have 2 process supervising each others.

Of course, in practice, crashes do not happen that much, so most people do not care or do not try to understand why it happens. But thinking "exceptional cases do not count" is not really inspiring confidence. People keep talking on how initscript are good, but that's crap. Take openbsd init scripts. They do matching based on process name. So one can just create a process, rename it, and suddenly, the initscript is confused. Debian bind script suffer from the same kind of race condition on PID reuse, due to the asynchronous nature of rndc communication with the main daemon. Yeah, that's the kind of stuff that happen almost never for a single server. And that likely happen on a regular basis when you manage a big server farm.

[Gusar]

This tells me you take hack or attacker as hacking to spam or become part of a botnet.

No, I'm just saying that's the most common MO, so one should be concerned about a lot more than just PID1 security, and securing those other things should actually have top priority.

You''ve honestly never been hit with a denial of service attack from a competitor.

You can DoS a machine without attacking PID1.

If someone gained control of the blind user, they could use an exploit in he process manager to get root and therefore have control over the entire tree. They could delete data, harm the OS etc.

If someone gained access to the blind user, there's several things they could exploit to gain root, so I don't know why you're singling out PID1 as being extra special in this regard. Even with systemd, PID1 is *not* the largest attack surface.

Basically, you're giving way too much focus to PID1, just to create an anti-systemd argument, when in perspective other processes will much more likely be the target of an attack.

[interested]

This has been discussed in many systemd threads before - systemd tries to re-exec itself if it crashes, but re-exec is not 100% reliable. The kernel is the same, there is no "if systemd" hack there.

Which in the context of the original question (why would service/cgroup manager in pid 2 be better) does not change things. Pid 2 failing to re-exec does not kill the world; pid 1 failing to re-exec does.

If sysvinit or systemd fails to re-exec in a reliable way then it is a particular bug that causes problems, not something inherently flawed in eg. systemd.

Systemd is of course superior in every way to other Linux init systems when it comes to supervising PID1 and PID2 etc. PID1 (systemd) actually know whether PID2 or PID47 have crashed, and can restart them in an intelligent way, including not needlessly trying to restart a process if it crashes immediately twenty times in a row.

So who supervises PID1? Well, it is easy as pie to configure systemd to use a hardware watchdog to monitor if PID1 is responsive or not, and reboot the entire system if PID1 hangs. Since it is systemd, the reboot will be a fast one too :-). Systemd is simply designed with integrated support for watchdogs.

Anyway: the main point here is to illustrate that systemd has a total supervising chain of everything, including itself. It is designed to be extremely robust, reliable and safe, and be so in an easy manner.

Most motherboards these days have inbuilt hardware watchdogs: try "wdctl" from the "util-linux" package to see if your motherboard has a hardware watchdog.

For more info on watchdogs and systemd:

http://0pointer.de/blog/projects/watchdog.html

[TeamBlackFox]

Have fun wasting your time compiling broken ports and not having a package manager that fetches what you need quickly and in working order.
Also, enjoy slashing your wrists out of frustration on shell scripts and a crappy flaky init system that completely fucks itself completely over whenever one shell script does work properly. Truely, BSD ports are the real cluster fuck and so is their obsolete init system.

<Bliggle drip and toy throwing>

Hey, don't sock puppet. That BS is just kindergarten. Anyways BSD rc init is specifically designed to NOT break if a script in rc.d goes awry, so that's hogwash. Shell scripts are easier to debug and actually work unlike your systemd cack. Pkgng and ports are designed to provide a choice to the community and both work fine, when a port doesn't build the maintainer is very helpful unlike the unholy monsters that are the developers of Linux distros. BSD also derives many tools used in Linux. But, because of Linux being a GNU slave, their code is unclean and tainted by the GPL. The GPL is Marxism not freedom like the BSD or MIT licenses.

Yes, congrats to system because their code is way cleaner and more functional then BSD code. Just compare the two. BSD is a utter mess, horribly bloated and ugly to look at. Systemd code by contrast is clean, correct and so well thought out. The only code that?s cleaner and correct is the Linux kernel.[/QUOTE]

Launchd is a low priority port and yes, if it became the equivalent of systemd for Linux I'd leave BSD behind. I have no desire to use an OS that resembles or tries to be like Windows or OS X.

Thus far I actually like OpenRC because it preserves some of the advantages of shell scripts and is far less monolithic. Also it's BSD licensed so any of the BSDs could adopt it. However we have no need for something new for the present.

And anyways now that someone mentioned it, SELinux is horrible. It is like UAC under Windows except its persistent filth that interferes with the security I have already in place on my deprecated OpenVZ Linux machines. I have no choice but to shut it off entirely. Thus another reason why OpenBSD is more secure, it actually uses security that works and doesn't interfere with your attempts to harden the machine. FreeBSD is equally secure from my field testing, and it has the most advanced filesystem, ZFS for use in the system by default. It makes BTRFS look like a blood sucking tick.

[nachoig]

No wonder your link points to RedHat website. And no wonder systemd is their creation. Of course they don't want Linux to be about choice. They want to get all the money and total control over the ecosystem while the community does the bulk of the kernel and userland development for free.

That's how it was marketed in the first place: "fast boot times!", "see, we are faster than windows!"... and it has become a gigantic monster, fed, it seems, by the gigantic ego of its creator.


I've been using linux for 8 years (I'm relatively young)... currently using Ubuntu 13.10, but I'm starting to think about changing distro, or even OS...
I'm a infosec enthusiast, that's why we think alike.


Wow, the irony here is astounding! Have you read the arguments given by people defending systemd? "systemd also supports scripts", "you can use other init system", ... also, have you seen what RED HAT IS DOING? they are developing: a DE, an init system, a network manager, etc. Exactly the contrary of what the guy wrote... as if there were none before they started developing them. BTW, I wonder what RMS or Linus think about that post.
.

I think systemd support scripts just for legacy reasons. The service files are much better than those init scripts.

And you don't have any idea of what is the cost to provide. I'm talking about real world. Choice is a beautiful word when you don't have to develop a way to these choices work, you simply choice and doesn't do anymore.

BTW, as you said you are an infosec enthusiast, just to remember: thanks to systemd technologies, we won't need to run Xserver as root anymore.

[gens]

...
BTW, as you said you are an infosec enthusiast, just to remember: thanks to systemd technologies, we won't need to run Xserver as root anymore.

you can run x rootless for a while now
thank X devs for that, systemd had nothing to do with it

only reason why not many distros do that is that a user needs privileges to read /dev/input/* (maybe even write, idk; also tty's, but that is another thing)
should be easy to set up, check the many tutorials on how

maybe libinput (the wayland spawned thing) should take care of this (didn't check thou)

i don't know of many things made possible with systemd "technologies"
can't think of one actually, maybe you can point some out

[Luke]

If you can write scripts, you can quickly learn to write service files

I think systemd support scripts just for legacy reasons. The service files are much better than those init scripts.

If you need to run a custom script-or a custom binary, you can write a service file to trigger it. If you are new to systemd (as I am), the best way to do this is probably to crib code from a service file that runs at the same time and in the same way as your desired program.

Example: When I ported my multi-encrypted disk unlocker to dracut/systemd, I first ran it as a dracut hook in initqueue. I soon found it started more quickly if called directly by systemd, but at first this caused a bug: systemd would be closing down the initramfs daemons before all non-root volumes could be unlocked if there were more than two of them, one using a keyfile, or one needing a diferent passphrase. Since systemd was able to call and then wait for the dracut hooks, obviously this could be stopped. I borrowed some of the code from dracut-initqueue.service for my own service file, and the problem was fixed. Custom initramfs boot script in /sbin with systemd and dracut (ported from debian unstable) in Ubuntu, hell yeah!

Boot times with systemd and systemd in the initramfs is about 5 seconds faster than with Upstart and initramfs-tools, though benchmarking boot times with a long passphrase requires a lot of timed test runs to average out passphrase entry times. A lot of the debugging came down to using "DefaultDependencies=no" to get out of a circular dependency. Systemd was actually smart enough to respond to a circular dependency by killing the offending process, re-resolving the process dependencies, and attempting to keep going.