Why systemd is the way forward: technical arguments

[twoflowers]

CPU usage: wheezy takes ~ 5%. squeeze was ~ 3%. FreeBSD is about 3%. Statistics almost the same on all my computers, even ARM.

[drokmed]

This is worth a read:

https://wiki.debian.org/Debate/initsystem/systemd

I just read that link... holy crap!!! Sounds like way much more than just an "init system replacement". Why does an init system need to take over the keyboard, console, user logins, and other operations AFTER the system is up and running? Where does it end?

Having been away, i'm just now coming up to speed on all this systemd controversy. It looks to me if you give systemd an inch, and it will take every last mile, and anything else after that.

If they just kept it as an init replacement, I could see that. But to keep growing like the blob, consuming all future functionality, that's not cool.

[golinux]

+1, drokmed. You have seen the light!

[twoflowers]

LOL ... I've seen the light and it was pitch dark

[tomazzi]

This is worth a read:

https://wiki.debian.org/Debate/initsystem/systemd

I just read that link... holy crap!!! Sounds like way much more than just an "init system replacement". Why does an init system need to take over the keyboard, console, user logins, and other operations AFTER the system is up and running? Where does it end?

Having been away, i'm just now coming up to speed on all this systemd controversy. It looks to me if you give systemd an inch, and it will take every last mile, and anything else after that.

If they just kept it as an init replacement, I could see that. But to keep growing like the blob, consuming all future functionality, that's not cool.

This wiki has been written as if systemd was a stable software, while if fact it's not.
And definitely it was even less stable at the time when the text was written.

As a result, and unfortunately, the wiki contains mostly misleading informations, half-truths, if not just lies.
For example:

Sysvinit/insserv has very little C code, but the real code size must take shell scripts into account. These scripts come in huge numbers, contain bugs and are hard to maintain.

The above suggests, that on the contrary, systemd has a lot of C code (what happened to be true) and is easy to debug (to find where the problem is...)
I can't imagine what kind of an idiot have written this. For sure, he heve never even readed the systemd code, not to mention trying to debug it.
And systemd has tons of bugs, which are not a result of the current alpha development stage - those bugs are effect of bad design, bad coding practices and ignorance.

Even the first listed feature of systemd is simply a lie:

Systemd uses control groups to ensure that any service, regardless of its state, can be shut down properly.

It is obvious, that services which are dealing with databases or filesystems in general cannot be "shut down properly, regardless of its state"
But, this is only tip of the iceberg, problem with this kind of aproach is far more deeply rooted:
Those idiots are running sync() calls in several threads, to make in parallel - but unfortunately storage devices are "serial", calling sync() in parallel is simply stupid and pointless.
Things are even worse: those idiots are running sync() in detached threads - what means, that they are not waiting untill sync() is finished and are turning the power off. It is very likely that systemd can corrupt file system in this way.
This may not be visible on desktops, where usually filesystem is in sync long before the user will shut down the system, but on servers this stupidity may have serious concequences.

Regards.

[edbarx]

Another brilliant post by tomazzi. Thanks for taking the time to explain technically what are the issues regarding the adoption of systemd at this inopportune stage.

[Head_on_a_Stick]

@tomazzi -- are you feeding back all of this information to the systemd development team? (Without the ad-homenim attacks, obviously)

It sounds like they could use your help...

[twoflowers]

The systemd devteam actually knows all this.

[Head_on_a_Stick]

^ Ah, it was the proligate use of the term "idiots" that led me astray on that one...

Please stop the personal attacks guys -- if there is a solid technical point to be made, surely you can see that attatching ad-hominem attacks to it dimishes your argument?

[drokmed]

Can I call myself an idiot if I don't become alarmed?

Again, excuse my ignorance, I've been away, but if systemd really is this out of control monstrocity that also appears to have serious design and implementation flaws, then why are nearly ALL of the linux distro's already embracing it? The old init scripts have their problems, sure, but they still work, maybe not at light speed, but they work.

Please endulge me, I have two thoughts on where this will go:

1. With all of this exposure, whether systemd stays in linux or not, will be forced to clean up it's act, fix all bugs, pull back on the "exceeding purpose", etc, which is a good thing. If they do all of these things, then it could become a good thing. Big IF's though.

2. Fortunately for us, many linux system administrators also have UNIX experience. After all, it's been around a LOT longer than linux. I won't go into a history lesson "do you remember when...", but I'm sure this controversy, justifiable or not, will cause a LOT of servers to move over to the BSD line. I left BSD years ago, because linux had much broader support in packages and hardware. That's not the case today. BSD has caught up, not entirely to be sure, but enough to move mission critical servers. That's a no brainer.

If systemd ever does become cleaned up, and even acceptable, it will be too late for servers. Friends of mine moved their servers to BSD years ago. I resisted, but now, it's the smart thing to do.

One other thing... the BSD folks also want to replace the aging init system with something better, but with what? I don't know the answer to this one yet, i'm still coming up to speed. I have a feeling they will do it right. Slow, but right.

Sorry to resurrect an aging thread, and thanks for the active responses.

It breaks my heart to see this happening to linux. It's like catching your wife cheating with someone you despise. Do you accept it, work with her, kick his tail, or do you sleep with his wife, dump them both, then move on down the road. Both options suck.

[tomazzi]

More on the sync() problem in systemd: (v218)
What I said before, is a tip of the iceberg which is only tip of another monstrous iceberg :
The asynchronous sync I've mentioned before is rarely used in systemd core, and this is much worse:
core/unit.c.3430: int unit_kill_context(): to big to put it here, so this is only the interesting part:
core/unit.c.3502:

Code: Select all

                if (r < 0) {
                        if (r != -EAGAIN && r != -ESRCH && r != -ENOENT)
                                log_unit_warning_errno(u->id, r, "Failed to kill control group: %m");
                } else if (r > 0) {

                        /* FIXME: For now, we will not wait for the
                         * cgroup members to die, simply because
                         * cgroup notification is unreliable. It
                         * doesn't work at all in containers, and
                         * outside of containers it can be confused
                         * easily by leaving directories in the
                         * cgroup. */

                        /* wait_for_exit = true; */

                        if (c->send_sighup && k != KILL_KILL) {
                                set_free(pid_set);

                                pid_set = unit_pid_set(main_pid, control_pid);
                                if (!pid_set)
                                        return -ENOMEM;

                                cg_kill_recursive(SYSTEMD_CGROUP_CONTROLLER, u->cgroup_path, SIGHUP, false, true, false, pid_set);
                        }
                }

Again: this the latest version of systemd: and practically every single service can be killed by power-off without any syncing (!)

/* FIXME: For now, we will not wait for the
* cgroup members to die (...)

How this is different from Winblow's "WaitToKillServiceTimeout"?
And obviously it's cgroups' fault, not systemd's

Back to asynchronous sync() (as they are calling it):
Making asynchronous (running in parallel) sync() is an evidence, that the devs have completely no idea what is sync for.
They are complaining:

/* It kinda sucks that we have to resort to threads to
* implement an asynchronous sync(), but well, such is
* life.

Well, this is stupidity in a flawless form.
The call to sync() is used to make sure that modifications made to a file up to *now* has been safely transfered to HDD - the program *must* wait before the file gets synced.
So for example, we can know, that the file in consistent state, before we start to append/modify other data or related files (especially important when dealing with database records and indexes).
So making a call to sync() asynchronous is plainly stupid, because this is exactly the oposite to what sync() is supposed to do... (!)

As this is used f.e. by journald, then it's quite probable that for this reason it randomly fails to save correct data.
But, who cares - "Just ignore it!"

Can I call myself an idiot if I don't become alarmed?

No, systemd was forced by former RedHad employees, who are now holding key positions in Debian structures.
They have decided for the users and for halve of Debian developers - that's all.

Regards.

[twoflowers]

That's te reason why "agile programming" discurages commenting code

Nice work!

[Head_on_a_Stick]

@tomazzi -- thank you for posting that without the personal attacks.

I don't understand any of it, but it sounds a lot more credible that way

[dasein]

...attatching ad-hominem attacks to it dimishes your argument?

Same thing true for typos?

(Sorry, couldn't resist when I saw it)

[buntunub]

It's like catching your wife cheating with someone you despise. Do you accept it, work with her, kick his tail, or do you sleep with his wife, dump them both, then move on down the road. Both options suck.

That entirely depends on what his wife looks like.

[tomazzi]

@tomazzi -- thank you for posting that without the personal attacks.

I don't understand any of it, but it sounds a lot more credible that way

Oh, You don't understand?
Well, that's what changed till I've visited Debian Forums long ago, before registration...
Debian gets popular, and as a consequence it has a lot of users, who don't really understand what Debian is (or was...)

Systemd, in my opinion, is broken by design - I'm working on a fork of it, because I don't want my OS to be broken by such a crappy software. My OS is my tool - I'm using it to work, seriously. Unfortunately, Debian TC have decided to polllute my OS with such a crap as systemd is, and apparently they have no idea of what they did.
This will result in thousants of patches to patches - as the Debian team haven't learned the lesson of pulseaudio, and they've forgot that init system is the cruitial part of the OS...

I don't know whether Debian was intentionally undermined (but it seems it was). The only value of this OS is now the number of packages it has. But, since I'm able to recompile them all, then I'm not tied to this particular OS forever...

However, when my fork of systemd (and dbus) will be working, I'll make it available for download - so everyone who's interrested can try it. Until then, I'm going to use Wheezy - which is free from the insanity introduced by systemd...

...and since I'm doing it for myself, not for the company, then by definition, this project will have better chances to be better...

Regards.

<edit>
I'm really pissed off due to a fact, that systemd was forced on me (and on all the users). I really don't wan't to re-write the systemd, as I have better things to do. But it's just a necessity if I want to use future versions of Linux without that shitty code of systemd.
It's beyond my understanding, how it is possible that such a big company as RedHat have chosen such bunch of uneducated fools to write such critical part of a system.
Practically, in every C unit file at least few critical bugs can be found... (like ignoring return values, etc) this is madness...
I'm guessing that the decision of adopting this crap was made only basing on a wiki - nobody in the TC have even tried to read the sources (with understanding) ....
</edit>

[twoflowers]

Enjoy reading:

http://ma.ttias.be/whats-new-systemd-2015-edition/

My favorite:

* read ahead implementation dropped: in the age of SSDs the benefit is not
big enough to have this. All systemd developers have SSDs and no more
spinning disks, nobody could/wanted to support this anymore. The idea was
to read-ahead the bits needed during the boot process and remember it next
time, for faster boots. But with SSDs, this support is dropped.

[Head_on_a_Stick]

Enjoy reading:

http://ma.ttias.be/whats-new-systemd-2015-edition/

My favorite:

* read ahead implementation dropped: in the age of SSDs the benefit is not
big enough to have this. All systemd developers have SSDs and no more
spinning disks, nobody could/wanted to support this anymore. The idea was
to read-ahead the bits needed during the boot process and remember it next
time, for faster boots. But with SSDs, this support is dropped.

Make your mind up -- do you like the fact the systemd offers support for a plethora of different functions or not?

All these features are optional except the "stateless system" paradigm -- that one raised a few eyebrows even on the Arch forums...

There are many independent read ahead implementations on offer in GNU/Linux, just as there are udev alternatives.

If you have a problem with any of them then use something else, just as you would with any other component of a GNU/Linux operating system.

All this nonsense about not adhering to UNIX principles (based on a single soundbite by Doug McIlroy) blissfully ignores the fact that all the tools for UNIX (the C library, the kernel, etc) are all maintained in the same repository and they are all released in sync, have the same coding style, the same build infrastructure and the same release cycles -- everything's the same. If anything systemd is making GNU*/Linux more like UNIX, not less. It's almost like all the people spouting off about this have never actually used UNIX at all...

* Remember: GNU's Not UNIX!

[schnuller]

All this nonsense about not adhering to UNIX principles (based on a single soundbite by Doug McIlroy) blissfully ignores the fact that all the tools for UNIX (the C library, the kernel, etc) are all maintained in the same repository and they are all released in sync, have the same coding style, the same build infrastructure and the same release cycles -- everything's the same. If anything systemd is making GNU*/Linux more like UNIX, not less. It's almost like all the people spouting off about this have never actually used UNIX at all...

I hought the main UNIX principle is "Do one thing and do it well"
Which is also the principle (or one ) of C (C is small, the rest is done in headers).
Assuming one can easily distinguish between the two at all (i doubt it).

You seem to be speaking of BSD, cause in Linux the kernel and the C library are sure not maintained in the same repository.

[schnuller]

* Remember: GNU's Not UNIX!

I guess the name GNU is often misunderstand as "Gnu is *not* Unix"

While it tries to point out that it is free (compared to UNIX):

GNU, which stands for Gnu's Not Unix, is the name for the complete Unix-compatible software system which I am writing so that I can give it away free to everyone who can use it

and to give credit to UNIX (give credit by making fun of is not seldom to be found, at least in hackerspace).