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

[Vim_User]

It is a guestimate, but so many things point in that direction: the total lack on any development on even critical components for non-systemd platforms is a good indicator that systemd opponents are a tiny minority.

But it is simply a fact that the majority (as in big and important and having many users) of all Linux distros are changing to systemd. Even on Gentoo and Slackware people are busy implementing systemd, it is just a matter of time before they too becomes de facto systemd platforms.

Your claim was about users, not developers. For your claim about systemd and Slackware: None of the few Slackware developers work on that. There are a few Slackware users who ported it to Slackware for experimenting with it, nothing more.

Yes they did. The technical committee did made the decision that systemd is the new default init system for Debian Linux. The decision was made exactly in accordance with the democratic processes as outlined in their rules. It is a clear decision: there is no doubt about the fact that systemd is the new default init system for Debian Linux.

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.

You should have read on; the point is that it should be initiated and controlled by the init system in such a way that there will be logging info from all processes from the moment the system is boot strapped, until the exact last micro second the system shuts down. This is something systemd can do because of its design, but that script based init systems that rely on syslogd can't.

That didn't answer the question. Why could systemd with syslog{d,-ng,whatever} not provide early logging? Why could the logging daemon not be controlled by systemd?

Don't believe me? Well, how about a Debian/Hurd developer:

"During gsoc last year I had to patch our procfs to finally be able to safely shut down Debian/Hurd systems using sysvinit. The problem was, that sysvinit at certain runlevel transitions (like shutting down, or I guess, switching to single user mode), sysvinit assumes that it is okay to stop and kill (almost) all processes on the system (that's what killall5 does). This might be okay on monolithic systems, but on (multiserver) microkernel systems like the Hurd, where your root filesystem and your network driver and stack are running as userspace processes, it is clearly not."

https://teythoon.cryptobitch.de/post...-init-systems/

The fact is that even on Linux sysvinit systems, it requires hack upon hack to make sysvinit work. This is probably why the sysvinit code base is so bloated despite the fact it is only capable of doing simple things. (and not even doing them correctly).

He clearly states that this is problem with micro-kernel systems, but it still not the truth that sysvinit on Debian will randomly shut down services. You actually may want to have a look at how that works on Debian.

The same thing as when a text file is corrupted; read as much as you can, which journalctl actually do very well. The systemd journal is exactly designed in such a way that if a process mangles and corrupt an entry, it doesn't affect the rest (append based). But unlike normal syslog files, there is actually a default log consistency check, so you can even know that corruption has happened. The journal file is a huge improvement in every way above the old text dumps. The power of the indexed journal and journalctl, even makes it much simpler to use standard Linux text tools such as "grep" to find what you need.

All this information and much more too is readily available on the systemd site:

"The systemd journal stores log data in a binary format with several features:

Fully indexed by all fields
Can store binary data, up to 2^64-1 in size
Seekable
Primarily append-based, hence robust to corruption
Support for in-line compression
Support for in-line Forward Secure Sealing
"
http://www.freedesktop.org/wiki/Soft...journal-files/

OK, I stand corrected on that.

[Ericg]

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?

https://unix.stackexchange.com/questions/86206/journalctl-verify-reports-corruption

Corruption applies on a line-by-line basis. If one line is corrupt, you jump to the next line and try again. Journalctl will output the first full line it can actually get a handle on. And since the text files are rotated on a user-defined-basis you can ease corruption by having it rotate frequently, say every... 10mbs or so? This way even an unclean shutdown should only affect the most recent log. And if you are experiencing LOTS of corrupted logs I'd be looking at filesystem bugs, or a failing drive.

EDIT: Also, check out: http://www.reddit.com/r/linux/commen...nd_corruption/

And remember, journalctl doesn't have to REPLACE syslog. You can use journal 99% of the time and have it set up to also forward all logs to syslog if you're really worried about corrupted binary logs, that way you have fast binary logs but visible text log backups.

[interested]

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.

It is a guestimate, but so many things point in that direction: the total lack on any development on even critical components for non-systemd platforms is a good indicator that systemd opponents are a tiny minority.

But it is simply a fact that the majority (as in big and important and having many users) of all Linux distros are changing to systemd. Even on Gentoo and Slackware people are busy implementing systemd, it is just a matter of time before they too becomes de facto systemd platforms.

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.

Yes they did. The technical committee did made the decision that systemd is the new default init system for Debian Linux. The decision was made exactly in accordance with the democratic processes as outlined in their rules. It is a clear decision: there is no doubt about the fact that systemd is the new default init system for Debian Linux.

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?

You should have read on; the point is that it should be initiated and controlled by the init system in such a way that there will be logging info from all processes from the moment the system is boot strapped, until the exact last micro second the system shuts down. This is something systemd can do because of its design, but that script based init systems that rely on syslogd can't.

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.

Don't believe me? Well, how about a Debian/Hurd developer:

"During gsoc last year I had to patch our procfs to finally be able to safely shut down Debian/Hurd systems using sysvinit. The problem was, that sysvinit at certain runlevel transitions (like shutting down, or I guess, switching to single user mode), sysvinit assumes that it is okay to stop and kill (almost) all processes on the system (that's what killall5 does). This might be okay on monolithic systems, but on (multiserver) microkernel systems like the Hurd, where your root filesystem and your network driver and stack are running as userspace processes, it is clearly not."

https://teythoon.cryptobitch.de/posts/on-portability-of-init-systems/

The fact is that even on Linux sysvinit systems, it requires hack upon hack to make sysvinit work. This is probably why the sysvinit code base is so bloated despite the fact it is only capable of doing simple things. (and not even doing them correctly).

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?

The same thing as when a text file is corrupted; read as much as you can, which journalctl actually do very well. The systemd journal is exactly designed in such a way that if a process mangles and corrupt an entry, it doesn't affect the rest (append based). But unlike normal syslog files, there is actually a default log consistency check, so you can even know that corruption has happened. The journal file is a huge improvement in every way above the old text dumps. The power of the indexed journal and journalctl, even makes it much simpler to use standard Linux text tools such as "grep" to find what you need.

All this information and much more too is readily available on the systemd site:

"The systemd journal stores log data in a binary format with several features:

Fully indexed by all fields
Can store binary data, up to 2^64-1 in size
Seekable
Primarily append-based, hence robust to corruption
Support for in-line compression
Support for in-line Forward Secure Sealing
"

http://www.freedesktop.org/wiki/Software/systemd/journal-files/

[Chousuke]

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?

You restore the log files from a backup? I'd rather take a logging system that tells me that my logs are corrupted and provides structure to them than a logging system where it's just text and you can't even tell if your logs can be trusted.

If you really must have your logs in textual format, it's pretty easy to configure journald to output its logs to text files or eg. this: http://www.freedesktop.org/wiki/Software/systemd/json/ The binary format is not a problem.

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

[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).

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

[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?

[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!

[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?