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

[markus40]

Udev and HAL lesson.

1. A bit more code, yes. But I would say the maintenance burden is lesser. The implementation is a bit more work - this is a trade off for simpler maintenance.
2. Well, any more code has the potential of introducing bugs. However, I think separate, simpler processes as opposed to a more complex single one tend to be less buggy. As well as that, my branch of Runit does not even allocate any heap memory in the init process, nor the service scanner.
3. PID 2, which is the service scanner, is not necessarily invulnerable to exploitation. But it's simple and exposes only a few interfaces, so I don't think it's too likely that there is a security issue.
4. Init (PID 1) has a simple fork-exec-wait-repeat mechanism, which will relaunch the service scanner (PID 2) if it dies. Though, like I say, it shouldn't die - the code is simple enough that I can see no potential cause.

The only real good argument I see sometimes is what must run in PID 1. Although PID 1 under systemd isn't large and doesn't do much, the anti systemd side claims it could and must do less. Mentioning the security, stability and Unix philosophy. For those I want to make a flashback to the past with udev and HAL. Ever wondered where HAL is gone? It is swallowed by udev. Initial udev and HAL worked together as separate processess with udev doing the bare minimum. Just like the anti systemd crowd claims systemd should do. Well, time learned that keeping those two separated could cause a lot of problems in te inter-process communication, which made the code of hal unnecessarily complex. The problems and complexities were magically reduced by integrating the HAL part in udev. Maybe something to remember in the argument of separation of tasks in plumbing. Sometimes the inter-process communication can cause a lot more trouble then handling it in one process, especially when they are so dependant and intertwined and the solution is a mere 5K process. You don't want something like race conditions fuck up your init do you? And imagine how juicy inter process communication is as a attack surface, especially so low in the plumbing. Sometimes it is better to choose wisely what you want to do as separate task, Unix philosophy or not.

I always enjoy the systemd discussions and as a extra bonus they are always really long. Plus I get up to date with what is going on in the lower areas of the Linux plumbing, thanks to some of the well informed pro-systemd opponents. Everytime well worth the read. The pure hatred, cheap personal shots of most of the anti arguments and the inability to come up with a alternative is what make those threads shine. You would expect by know the BSD crowd should match the numbers of Linux developers if you believe the defection numbers of highly qualified anti systemd opponents.

[curaga]

This isn't correct. If systemd dies, it just freezes and doesn't crash anything. You cannot start/stop services but the existing services will continue running.

That is not what happens in a kernel panic.

[curaga]

Rahul, it is very simple to prove a kernel panic kills the world, and pid 1 dying panics the kernel. Have a Qemu screenshot from a session with init=/bin/sh:



I pressed ctrl-D to kill the shell, pid 1, and voila, kernel panic. Witness how existing services do not continue to run.

[interested]

You reply is ambiguous in regard to what you disagree. Is it that you will likely never be convinced or that there will never be valid criticisms?

If it is the latter, that seems pretty improbable that so many people are all totally wrong and that only you possess the truth. IMHO, that even sound arrogant.

What I meant was that I haven't seen any valid systemd criticism in this thread. What I do see is an embarrassing lack of knowledge on how systemd works, that makes the systemd opponents make wildly wrong claims about how systemd works.
As I said, when people people actually examine systemd by studying it and reading the documentation, they discover that the systemd opponents claims are wrong. This is one of the reasons why systemd have won over all major Linux distros.

Regarding the "many people" who oppose systemd: As I said, systemd opponents like to flash mob systemd threads. This gives them the very wrong impression that they are anything but a very tiny minority. The fact is that the overwhelming majority of Linux users likes systemd, and that systemd opponents are a tiny but vocal minority.

The Debian debates really illustrate this very well. After a very long and intense debate over whether Debian should adopt systemd as the default, the technical committee decided in favour of systemd. The systemd opponents could start an overturn of that decision by just getting 5 named Debian developers out of +1000 to support a resolution. They couldn't even manage that. I repeat; the systemd opponents were unable to get even five people out of thousands to put their name on that resolution.

That systemd opponents are so few, probably also explains why there is no maintenance of critical parts of non-systemd platforms.

As init system, systemd does a pretty good job and even introduce many cool ideas.

The problem that I have with systemd, it is that is taking over system logging and network services.

DHCP or inetd has nothing to do with init.

Was the legacy DHCPd Sw broken? If not, what is the point of concentrating logging and basic networking services into systemd?

Providing a honest explanation might convince me but replying that this can be disabled if I do not like it, is not an answer to the question because:

You could have answered these questions yourself if you had read enough about systemd. But let me briefly explain. Systemd has a "metal-to-metal" concept. That means that it aims to have full control over all processes, from the very micro-second the kernel is bootstrapped, to the very last micro-second when the power is off. It wants to fully control all processes; in exactly what order they start and stop, what they are allowed to do, and what resources they may use, and total knowledge about what they communicate etc.

All the major design decisions in systemd revolves around this "metal-to-metal" concept of full control. This includes logging.
It quickly becomes very obvious, that if the logging system itself is a daemon that starts late, it can't provide logging info about early boot or late shutdown. It is really obvious that in order to get such logging info, logging must be initiated and controlled by the init system.

One of the many problems with script based init systems is that when they shutdown they just issue a massive "kill all processes" which is done in random order. So they may kill the logging system before any other daemons, leaving no traces of the rest of the shutdown process. In micro-kernel systems like Hurd were even file-systems are user processes, this means that sysvinit or rc.d could randomly kill the filesystem as the first process, thereby making the system hard crash in a panic.

Since systemd have total control over all processes, it can intelligently shutdown the system and guarantee that both file-systems and logging are killed off as the very last thing.

So if you want total control over processes, including their logging info, you just have to invent another logging system than good old syslogd.
Once you are down that road, it becomes really obvious to take the last step, in finally fixing logging on Linux. This have been tried for over a decade with only limited success. It is not that syslogd is badly implemented, it is just the very nature of things, since logging have been totally uncoordinated on Linux, with basically unstructured text dumps that can't be changed since so many hacked together log watch scripts relies on brute force grepping, in fact making the unstructured text an API.

Journald and journalctl are superb implementations that really helps in debugging and make sense of the ever growing logfiles. They also enable GUI log viewers that just aren't a "less" pager with windows decorations.

systemd's logging system is huge improvement over the old style syslogd text file dumps. I could list page after page with examples on how much better it is, but I suggest anyone genuinely interested to try it out in earnest, and do some studying of the documentation.

But including the logging system in systemd is also a very natural thing to do, and is part and parcel of the overall design of systemd.

[Chousuke]

You reply is ambiguous in regard to what you disagree. Is it that you will likely never be convinced or that there will never be valid criticisms?

If it is the latter, that seems pretty improbable that so many people are all totally wrong and that only you possess the truth. IMHO, that even sound arrogant.

As init system, systemd does a pretty good job and even introduce many cool ideas.

The problem that I have with systemd, it is that is taking over system logging and network services.

DHCP or inetd has nothing to do with init.

See, this is what I mean when I said people misunderstand systemd.

System logging and network services have nothing to do with the init. Not even within systemd. Sure, journald and logind and whatever other components the project provides use services provided by the init (like cgroups management), but they are not part of the init system.

The confusion stems from the fact that there's a project called systemd that is a collection of tools which work closely together, one of which is the init binary / cgroups manager called systemd.

Was the legacy DHCPd Sw broken? If not, what is the point of concentrating logging and basic networking services into systemd?

Providing a honest explanation might convince me but replying that this can be disabled if I do not like it, is not an answer to the question because:

1. Most distribution will package systemd with all the bells and deprecate legacy packages
2. A minority have the knowledge and the determination to go through the trouble to disable the undesired features (Gentoo users a modern monks to compile everything, IMHO)
3. It does not says what are the benefits are of concentrating everything into systemd.

My take on the answer is that there is not really any technical benefit for the users but it is only a question of control and power.

A single project (company) will end up controlling and centralizing the vital part of a Linux system and Red Hat shareholders are probably cautionning that as eventually this should boost their dividends a little bit like MSFT shareholders were feeling in the 80s.

[/quote]
I'll just ignore the yet another vague mention of a Red Hat conspiracy...

Personally, I think journald integrating with init and the kernel is extremely useful! It can know for certain what processes are sending log data to it, when, where, and other information that you can't trust the service itself to provide. With integration, it can also provide you early and late boot logs. Personally, I find it very convenient that I can just run a status on a service and systemd will print me a bit of its log as well. I usually don't even know where its log file is and frankly I am not interested.

The rest of the tooling around systemd exist to provide a uniform core for Linux systems, since frankly choice in the matter of how you set up network interfaces is not very useful. It's just fragmentation. Perhaps other tools do not expose enough features, such as network namespaces?

[interested]

The problem that I have with systemd, it is that is taking over system logging and network services.

DHCP or inetd has nothing to do with init.

Was the legacy DHCPd Sw broken? If not, what is the point of concentrating logging and basic networking services into systemd?

Providing a honest explanation might convince me but replying that this can be disabled if I do not like it, is not an answer to the question because:

Besides the "metal-to-metal" concept about full control with all processes I have explained previously, systemd also aims to be a minimal plumbing system that developers can rely on, bringing some order in the total fragmentation chaos that exist between Linux distros. This is why it provides a standard place to put the "os-release" file.

It therefore enables developers to develop GUI and CLI utilities that works on all full systemd platforms, such as using ntp (regardless of what particular implementation the distro may use), and how to control the network etc.

As an extension of the "metal-to-metal" concept, systemd have 3 major tool series:
The init part (systemd)
The logging part (syslogd)
The OS container part (nspawn)

Almost all new systemd features in recent times have revolved around OS containers, including the dhcp add-ons. There are special problems when systems aren't working directly on the bare hardware, but are virtualized. The aim with the networking part was to solve those problems, not provide a general replacement to dhcp clients. That it evolves at breathtaking speed is because the end-users are loving the concept and keeps on supplying patches: it works brilliantly on mass deployment of both OS containers and static hardware nodes.
It is not a general replacement for networkmanager or similar or even dhcp clients.

A single project (company) will end up controlling and centralizing the vital part of a Linux system and Red Hat shareholders are probably cautionning that as eventually this should boost their dividends a little bit like MSFT shareholders were feeling in the 80s.

Seriously, whats up with all that paranoia? Go to the systemd git repo and check out the names; systemd is a multi-distro collaboration with Debian and Arch developers and many more having direct commit access. It is easy as pie to fork it if anyone disagrees with the direction the project is taking.

If you really distrust Red Hat that much, you shouldn't be using Linux; period. Red Hat are _the_ major reason why Linux have commercial success. They have been involved in all the major developments of Linux for almost two decades, and have all that time shown an unwavering iron will and total commitment to open source.

Yes, Red Hat makes money from Linux, but if there wasn't any business interest in Linux, it would had died in its infancy as a phd. project for Linus. In fact, the whole idea about open source is that people with different interests, including monetary interests, all can benefit by contributing to a common pool.

Slandering Red Hat by trying to paint them as the Microsoft of the Linux world is a grotesque idea that can only be fostered in a circle of self affirming conspiracy nuts. Please have a reality check!

[Vim_User]

The fact is that the overwhelming majority of Linux users likes systemd, and that systemd opponents are a tiny but vocal minority.

If that is a fact you can show us the numbers that confirm that fact, can't you. Otherwise it is nothing but a wild guess.

After a very long and intense debate over whether Debian should adopt systemd as the default, the technical committee decided in favour of systemd.

No, they did not. They were overruled by their leader after having a tie in the votes. If it weren't for that leader the discussion would still going on. Don't make it sound like that was a clear decision.

The systemd opponents could start an overturn of that decision by just getting 5 named Debian developers out of +1000 to support a resolution. They couldn't even manage that. I repeat; the systemd opponents were unable to get even five people out of thousands to put their name on that resolution.

That sounds interesting, do you have a link on that?

It quickly becomes very obvious, that if the logging system itself is a daemon that starts late, it can't provide logging info about early boot or late shutdown. It is really obvious that in order to get such logging info, logging must be initiated and controlled by the init system.

Huh? Logging is always initiated by the init system, what else should start it? And if you start for example syslog-ng with systemd, how is it not controlled by it?

One of the many problems with script based init systems is that when they shutdown they just issue a massive "kill all processes" which is done in random order. So they may kill the logging system before any other daemons, leaving no traces of the rest of the shutdown process. In micro-kernel systems like Hurd were even file-systems are user processes, this means that sysvinit or rc.d could randomly kill the filesystem as the first process, thereby making the system hard crash in a panic.

Sorry, but that only shows that you have no clue at all how sysvinit works for example on Debian. It also shows that you are guilty of the same thing you accuse systemd opponents to be: Not knowing what you speak about when it comes to other init systems that systemd.

Journald and journalctl are superb implementations that really helps in debugging and make sense of the ever growing logfiles. They also enable GUI log viewers that just aren't a "less" pager with windows decorations.

systemd's logging system is huge improvement over the old style syslogd text file dumps. I could list page after page with examples on how much better it is, but I suggest anyone genuinely interested to try it out in earnest, and do some studying of the documentation.

What due you do with your binary log if the logfile itself becomes corrupted? With text based logging you may still be able to partially retrieve information from it, but how do you do that if journalctl simply answers with "log file corrupted" or something similar? How superior is it in that case?

[Luke_Wolf]

If you really distrust Red Hat that much, you shouldn't be using Linux; period. Red Hat are _the_ major reason why Linux have commercial success. They have been involved in all the major developments of Linux for almost two decades, and have all that time shown an unwavering iron will and total commitment to open source.

Yes, Red Hat makes money from Linux, but if there wasn't any business interest in Linux, it would had died in its infancy as a phd. project for Linus. In fact, the whole idea about open source is that people with different interests, including monetary interests, all can benefit by contributing to a common pool.

Slandering Red Hat by trying to paint them as the Microsoft of the Linux world is a grotesque idea that can only be fostered in a circle of self affirming conspiracy nuts. Please have a reality check!

For better or worse this is the simple reality, if Red Hat hadn't of backed linux we'd all be running BSD right now. Linux is very lucky that the stars aligned just right for it to have actually won out over the BSDs. Whether we'd be better or worse off for it I don't think anyone can say as there's too many other variables in play.

[beetreetime]

For better or worse this is the simple reality, if Red Hat hadn't of backed linux we'd all be running BSD right now. Linux is very lucky that the stars aligned just right for it to have actually won out over the BSDs. Whether we'd be better or worse off for it I don't think anyone can say as there's too many other variables in play.

You are wrong. Even if all the companies in the world back BSD and nothing backed Linux, we would be still using Linux not BSD. This is because of Linus' choice of the GPL license and the crappy BSD license.

Also more, companies supporting BSD means more corporate control of BSD code masking it crappier due to corporate meddling. BSD code is already heavy corporate controlled and crap so in your alternative world, BSD will even be more horrible while Linux just will rely on more heavily on donates (which unlike OpenBSD will be a lot).

[Ericg]

Rahul, it is very simple to prove a kernel panic kills the world, and pid 1 dying panics the kernel. Have a Qemu screenshot from a session with init=/bin/sh:


I pressed ctrl-D to kill the shell, pid 1, and voila, kernel panic. Witness how existing services do not continue to run.

If you're gonna prove him wrong curaga, you have to actually USE his claim. Redo your experiment with systemd, post THAT pic. I've never tried killing pid1 systemd, but it could be setup to run different / have a catch in the kernel to NOT cause a crash.