Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

From the systemd source code

Here you can discuss every aspect of Debian. Note: not for support requests!
Message
Author
bdtc1
Posts: 42
Joined: 2015-01-22 09:00

From the systemd source code

#1 Post by bdtc1 »

Scanning comments from the Jessie version of a few random systemd files:

From logind.c:

Code: Select all

        /* On certain architectures (S390 and Xen, and containers),
           /dev/tty0 does not exist, so don't fail if we can't open
           it. */

(but they don't check the current architecture)

From execute.c:

Code: Select all

                /* Drop privileges - we don't need any to pam_close_session
                 * and this will make PR_SET_PDEATHSIG work in most cases.
                 * If this fails, ignore the error - but expect sd-pam threads
                 * to fail to exit normally */
From mount.c:

Code: Select all

                /* FIXME: we need to do something here */
From unit.c:

Code: Select all

                       /* 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. */
From switch-root.c:

Code: Select all

        /* When using pivot_root() we assume that /mnt exists as place
         * we can temporarily move the old root to. As we immediately
         * unmount it from there it doesn't matter much which
         * directory we choose for this, but it should be more likely
         * than not that /mnt exists and is suitable as mount point
         * and is on the same fs as the old root dir */
(then they go ahead and use /mnt)

From service.c:

Code: Select all

        /* This will leak a process, but at least no memory or any of
         * our resources */
also:

Code: Select all

                /* FIXME: we need to do something here */
(three instances, plus another different FIXME)
also found some humor:

Code: Select all

                /* Uh, we sent a SIGKILL and it is still not gone?
                 * Must be something we cannot kill, so let's just be
                 * weirded out and continue */
From transaction.c:

Code: Select all

                /* Are there any jobs now? Then make sure we have the
                 * idle pipe around. We don't really care too much
                 * whether this works or not, as the idle pipe is a
                 * feature for cosmetics, not actually useful for
                 * anything beyond that. */
For what it's worth, strictly from the point-of-view of structure and read-ability, the code isn't the worst stuff I've seen. It could use many more comments, but at least has plenty of white space and structure, and the functions are (mostly) not too huge or nested too deeply. This says nothing at all about the quality of the functionality of the code, of course. It could be interesting to grep all the FIXME comments and see what comes up, for example.

spacex
Posts: 637
Joined: 2015-01-17 01:27

Re: From the systemd source code

#2 Post by spacex »

ROFL. At least that's a funny take on it :lol:

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: From the systemd source code

#3 Post by tomazzi »

bdtc1 wrote:This says nothing at all about the quality of the functionality of the code, of course
What You've presented is only a tip of the iceberg ;)

But even those few quotes are showing the obvious truth: there are many areas in systemd which were *never* tested - instead, the authors are writting excuses and are jauntily guessing that *probably*, *somehow* or *likely* their code will work, hopefully without crashing or falling into undefined state...

Well, I know only one term which is appropriate for such kind of software: CRAP.

But, taking into account, that this crap is used to control the whole OS, I think that even more appropriate term would be: dangerous crap.

sleep well ;)

Regards.
Odi profanum vulgus

User avatar
NkfzGx3ok
Posts: 20
Joined: 2014-10-30 12:08

Re: From the systemd source code

#4 Post by NkfzGx3ok »

tomazzi wrote: Well, I know only one term which is appropriate for such kind of software: CRAP.
But, taking into account, that this crap is used to control the whole OS, I think that even more appropriate term would be: dangerous crap.
So just for peace of minds sake before I waste my time at some point: If I have an ack through the sources of say... sysvinit, linux kernel, glibc as basic blocks for the system I will not find a single FIXME (let alone one containing ?'s) and certainly no "probably", "somehow" or "likely" in the comments because work-arounds and assumptions have had to have been made?

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: From the systemd source code

#5 Post by tomazzi »

This is a *complete* list of Fixme's for sysvinit 2.88: (all from init.c)

line 312: (in fact this a TODO)
* Read a string from a file descriptor.
* FIXME: why not use fgets() ?
line 1150: (TODO)
* Do NOT log if process field starts with '+'
* FIXME: that's for compatibility with *very*
* old getties - probably it can be taken out.
line 1644
f (delete) {
/* FIXME: is this OK? */
ch->flags &= ~(RUNNING|WAITING);
if (!ISPOWER(ch->action) && ch->action != KBREQUEST)
ch->flags &= ~XECUTED;
ch->pid = 0;
} else (...)
line 2158: (in fact this is TODO/MISSING, but also obsolete note)
* Read from the init FIFO. Processes like telnetd and rlogind can
* ask us to create login processes on their behalf.
*
* FIXME: this needs to be finished. NOT that it is buggy, but we need
* to add the telnetd/rlogind stuff so people can start using it.
* Maybe move to using an AF_UNIX socket so we can use
* the 2.2 kernel credential stuff to see who we're talking to.
That's ALL - in fact, there is only 1 Fixme, but the code works for over 20 years, so definitely it *is* tested.

Regards.
Odi profanum vulgus

somebodyelse
Posts: 231
Joined: 2015-05-24 17:15

Re: From the systemd source code

#6 Post by somebodyelse »

Make sure you file bug reports for any bugs discovered. Cold hard facts and data are your friends.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: From the systemd source code

#7 Post by tomazzi »

somebodyelse wrote:Make sure you file bug reports for any bugs discovered. Cold hard facts and data are your friends.
Actually I've reported 3 key design bugs to systemd developers. (links can be found on this forums)

One of the key RedHat devs couldn't understand what the hell I was talking about - because He didn't even understand the manpage for kill(2) ... not even funny...
Lennart P. on the other hand, said that he would accept "a patch" which will fix the problem: systemd is not able to catch its own stack overflows (among other things) - but "The patch" would need to rewrite systemd core from scratch.

So please...

I think that they should just remove the comments from the sources... - it won't make the systemd better, but at least it will reduce the number of topics like this one :) ...cough... not funny.
Odi profanum vulgus

somebodyelse
Posts: 231
Joined: 2015-05-24 17:15

Re: From the systemd source code

#8 Post by somebodyelse »

No, within Debian. Your aim is to make Debian see that systemd is a big pain in the arse, right? So, make this clear/undisputable by filing bug reports for each and every systemd bug you find. If you are right about systemd, the system will collapse under its own weight.

If you can't do that, maybe systemd is not so buggy.

I am on the fence about systemd. I am not on the fence about Poettering. He's an arrogant tit. But telling him that will only feed his ego so I wouldn't bother. And I also wouldn't bother dealing directly with the project.

User avatar
thanatos_incarnate
Posts: 717
Joined: 2012-11-04 20:36

Re: From the systemd source code

#9 Post by thanatos_incarnate »

somebodyelse wrote:filing bug reports
It's a religious war, not productive critique.

WeLoveDebian
Posts: 109
Joined: 2014-03-16 23:00

Re: From the systemd source code

#10 Post by WeLoveDebian »

I haven't read systemd's code yet, but from what I can see it's not too bad. And even if it was bad (which it isn't) Poettering and friends actually stood up to the Linux community and made what almost nobody else attempted to: creating standards, actual "building blocks" in which all Linux systems, regardless of being Ubuntu or SuSE, can use to make a ton of things better, and that work. Valve is doing that too.

Most poeple who complaint about systemd (and still do to this day) haven't moved a single finger to actually make Linux look like an actual "professional grade" operating system in regards to what systemd is mostly doing (because, let's face it, somethings are crappy). Sure, it has it's quirks, but what software doesn't have? Debian is a great distro but yet it has MANY flaws. Yet I still use it as my main system (mostly because it 'generally' works better than other distros).

The point of this message is: complaining servers no good to the community. If developers actually stopped caring about their own little asses we'd be light-years in front of the competition, we'd have one good sound system that works, one good and fast package format and one good and fast package manager, one AWESOME set of repositories filled with GPL drivers that worked for every hardware, one awesome and fast display manager, etc. But noooo, Linux developers (not the kernel developers) LOVE to fork and duplicate their efforts only to support a new thing that THEY think should be the gold standard, instead of improving existing things. Sure, that SOMETIMES is how good and better software appears, but for the most part it's useless effort. I wouldn't be surprised if a new distro came up with a "new and golden" package format because they think whatever is out there sucks. The end result? There are 2.002 distros, most of them have sound or video issues because there are at least 2 or 3 "standards" that break each other, tons of package formats and a lot of confusion for new users. Not to mention the hundreds of developers doing this useless work instead of, say, improving Xorg or making new wi-fi GPL drivers and firmware. I really hope they love their "freedom of choice" because that will do good only to a few people, not to mention it only makes adoption WORSE, specially for the few hundred users who, at the end, couldn't give a bigger crap if their packages are in .deb or .rpm or in a .zip file that tells the package manager "put this into /usr/bin". I mean, why improve, IDK, Xorg, when we can spend our time taking our maintained program upstream and package in our little precious format and making small adjustments, right? I mean, it's not like our system has other issues other than doing things our separate way. No.

And since we as a software community can't work together (because we LOVE to take credit for "our stuff", "my new sound system which is better than pulseaudio" or "my newly Iceweasel browser which is based off of Debian's Iceweasel and only contains minor changes and yet is still soooo superior", much like having our own babies instead of adopting children), smart players like Valve and Red Hat are stepping up and doing what should've been done 15 years ago: making Linux an actual EFFICIENT system which anyone can easily write software and make it better, fast. So, even though I hate to say this depending on the issue, systemd is doing us more good than harm. And if you think otherwise than please start talking to developers so they unite to create "a new standard that will beat systemd's design". I'm sure there are thousands of them willing to, once again, make the "Linux spinning wheel of useless efort" spin again.

Is it bad that systemd has a LOT of power to do things? Yup, but that's the price we all pay when nobody thinks outside the dated Unix philosophy or can't cooperate together (see above).
Last edited by WeLoveDebian on 2015-08-19 21:40, edited 1 time in total.

User avatar
keithpeter
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: From the systemd source code

#11 Post by keithpeter »

Disclaimer: I'm a civilian and I can write BASIC with GOTOs in any syntax you like :lol:

Just wondering if you took *any* large software-libre project and really started looking at the code how it would compare?

RedHat is a large company and has really bet the farm on this stuff working so I'd imagine anything serious will get fixed quickly but we all know what can lurk deep in the code files...

User avatar
NkfzGx3ok
Posts: 20
Joined: 2014-10-30 12:08

Re: From the systemd source code

#12 Post by NkfzGx3ok »

tomazzi wrote:This is a *complete* list of Fixme's for sysvinit 2.88: (all from init.c)
That is good and I didn't expect much from it but the point is sysvinit or systemd-init are really peanuts in the system when compared to the kernel, glibc, gcc and a whole bunch of little things not worth listing when it comes to using and controlling our systems.

I speak English for ~10 years but still make mistakes in understanding so I apologise if I am wrong but it seems to me you have laid out a set of rules/conditions in which you single out systemd as being "dangerous crap", yet if you set out to apply these rules on other important softwares you find it there too! It seems quite unfair to single out systemd if other basic building blocks mentioned also pass these conditions you set against systemd. Will you also in this public forum declare them dangerous crap and vow to stop using them? Change OS? Stop using computers altogether? Where does it end?! That they too also have them is most certainly not an excuse for systemd to have them, it is however unfair to single out systemd on the matter in my opinion.

keithpeter wrote:Disclaimer: I'm a civilian and I can write BASIC with GOTOs in any syntax you like :lol:

Just wondering if you took *any* large software-libre project and really started looking at the code how it would compare?

RedHat is a large company and has really bet the farm on this stuff working so I'd imagine anything serious will get fixed quickly but we all know what can lurk deep in the code files...
I did some quick and dirty based on what I consider important on the systemd I post this: linux, glibc and of course xserver.. results here:
glibc_fixme http://sprunge.us/QIUX
glibc_hack http://sprunge.us/aefB
glibc_likely http://sprunge.us/STeQ
glibc_probably http://sprunge.us/cIOQ
glibc_somehow http://sprunge.us/dMcI

kernel_fixme http://sprunge.us/OEIf
kernel_hack http://sprunge.us/FPMW
kernel_likely http://sprunge.us/aIPS
kernel_probably http://sprunge.us/PeYF
kernel_somehow http://sprunge.us/WiaB

xorg_fixme http://sprunge.us/LaYJ
xorg_hack http://sprunge.us/fdBb
xorg_likely http://sprunge.us/ghMh
xorg_probably http://sprunge.us/BAPf
xorg_somehow http://sprunge.us/EHeX
(warning: little context & as with anything of course possible false positives)

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: From the systemd source code

#13 Post by tomazzi »

Ah Yes, so now we have came to the point were it becomes necessary to understand what particular comment means in the context of related fragment of code. (well, it was predictable...)
I've already tried to this here (on this forums), but it quickly showed up that it's a waste of time - the code of systemd is too complex for most people to understand.

--------
I'm pretty sure some people here can see the difference just by reading the Fixme's on their own, so I'm not going to start another long and pointless debate on what's wrong (or not) with systemd.

Forgive me, but I have better things to do (f.e. I've started an early testing stage of a new service manager <no name atm> , and this takes a lot of time ;) )

Regards.
Odi profanum vulgus

User avatar
mor
Posts: 970
Joined: 2010-08-28 15:16
Location: mor@debian

Re: From the systemd source code

#14 Post by mor »

Fair enough, but it is not what NkfzGx3ok asked you.
It would be nice if you could answer to the merit of that question.

Also, have you by any chance come to know of some reliable statistical information about the supposed incidence on the field of systemd's dangerous proneness to failure?
Of course I mean for what would be worth so far, considering that adoption is probably still quite low on servers where both the danger and the chance of failure happening would be much higher.
It is just a curiosity that I had after reading one of you last comments, I figured that you must be quite interested in finding out something like that too, given how confident you are in your evaluation of systemd.

Bye

millpond
Posts: 698
Joined: 2014-06-25 04:56

Re: From the systemd source code

#15 Post by millpond »

Two of the things I hate most about Win are svchost. And the registry.

The init processes need to be transparent, or it simply is not Linux.

It is crucial in a world with the TXT bit, that there be no processes built into an Open Source system that can be used as a future launchpad for the evil it represents.

It was one thing when the propellorheads tried turning our desktops into toy phones with Gnome3/Unity.
We rebelled.

This is a beast that must be killed in its infancy. Because a centralized massive quasi-kernel will sonn require a massive datastore for its data. A nasty, bloody *registry*.

That will soon be populated by ever increasing corporate interests, and grow ever more cryptic.

I am in full support of anything that makes Linux user friendly.
But f**king up a time tested init system to save a few seconds at boot ime - aint it.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: From the systemd source code

#16 Post by Head_on_a_Stick »

millpond wrote:to save a few seconds at boot ime
http://forums.debian.net/viewtopic.php?f=20&t=120157
deadbang

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: From the systemd source code

#17 Post by tomazzi »

ehh...
mor wrote:Fair enough, but it is not what NkfzGx3ok asked you.
It would be nice if you could answer to the merit of that question.
NkfzGx3ok wrote:So just for peace of minds sake before I waste my time at some point: If I have an ack through the sources of say... sysvinit, linux kernel, glibc as basic blocks for the system I will not find a single FIXME (let alone one containing ?'s) and certainly no "probably", "somehow" or "likely" in the comments because work-arounds and assumptions have had to have been made?
[answer]
Yes, it is obvious that almost all sources are containing comments marked as "FIXME", "TODO", "HACK", etc.
But, there can be a huge difference between importance/severity of problems/suggestions which are expressed in this way. It is especially important to know how particular problem or workaroud affects the stability or functionality of a program, where by functionality I mean: expected behaviour, described in the official specification.
[/answer]

Example:
wiki: "<systemd> Tracks processes using Linux cgroups"
wiki: "<systemd> can safely shutdown service, regardless of its state" (removed, after I've pointed out that this was simply a lie)
Now:

Code: Select all

/* 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. */
What does it mean: It means, that actually systemd just can't track the processes, but also it can't even guarantee safe termination of a service process.

Now, if You'll read Fixme's listed in sysvinit, glibc, etc, You should be able to note one thing: they are mostly harmles side notes like f.e. "this can be done in a better way", and definitely none of the problems described there is affecting the stability or functionality of the code.
Can You see the difference?
------------
But there are even worse bugs, which are not even commented - they are silently ignored.
Systemd can be started without signal handlers installed - what means, that it can fall into undefined state (this is one of the bugs which I've reported). Apparently Lennart knew abut this bug, because he said that ~(more or less) "actually we don't know how to solve this, so we have decided to simply ignore it".
But: You won't find a single word about this in the related fragment of code.

Removing comments won't solve the problems.

Regards.
Odi profanum vulgus

User avatar
mor
Posts: 970
Joined: 2010-08-28 15:16
Location: mor@debian

Re: From the systemd source code

#18 Post by mor »

@tomazzi
My bad, I should have been more clear.
I was not referring to that bit you quoted, since between that and the post of yours I addressed, there was already a reply from NkfzGx3ok and a counter reply from you.

In the post right above yours NkfzGx3ok asked this, which follows the reply from the bit you quoted:
NkfzGx3ok wrote:
tomazzi wrote:This is a *complete* list of Fixme's for sysvinit 2.88: (all from init.c)
That is good and I didn't expect much from it but the point is sysvinit or systemd-init are really peanuts in the system when compared to the kernel, glibc, gcc and a whole bunch of little things not worth listing when it comes to using and controlling our systems.

I speak English for ~10 years but still make mistakes in understanding so I apologise if I am wrong but it seems to me you have laid out a set of rules/conditions in which you single out systemd as being "dangerous crap", yet if you set out to apply these rules on other important softwares you find it there too! It seems quite unfair to single out systemd if other basic building blocks mentioned also pass these conditions you set against systemd. Will you also in this public forum declare them dangerous crap and vow to stop using them? Change OS? Stop using computers altogether? Where does it end?! That they too also have them is most certainly not an excuse for systemd to have them, it is however unfair to single out systemd on the matter in my opinion.

Emphasis addedd
This is what I was referring to. ;)

By the way, do you have a word or two for my question?

Bye

User avatar
dasein
Posts: 7680
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: From the systemd source code

#19 Post by dasein »

I am gonna hate myself for rising to the bait...

For the benefit of those who may have somehow missed it the first time around, here is a handy link back to the post where tomazzi already clearly articulated the key differentiator. Anyone who isn't just trolling might want to read that post as many times as required until s/he can answer the question of why someone might legitimately imagine that systemd should be held to a higher standard than, say, Xorg.
mor wrote:By the way, do you have a word or two for my question?
I do: straw man.
Image

To be abundantly clear, when you ask for:
mor wrote:...reliable statistical information about the supposed incidence on the field of systemd's dangerous proneness to failure?
you're asking for data that:
(a) you know don't exist (or you would have at least linked to it)
(b) wouldn't actually address the underlying question even if it did exist

Worse, you're subtly implying ("supposed incidence") that unavailability of data is somehow equivalent to nonexistence of the phenomenon. (See https://en.wikipedia.org/wiki/Argument_from_ignorance)

WARNING: Actual math follows

Edit: In the absence of systemd-specific data, it's still possible to come up with a statistically serviceable estimate of the "supposed" incidence of the kinds of issues tomazzi is focusing on. A few years back, researchers at UC Berkeley undertook an aggregate analysis of failures in exception-handling code across multiple authors and multiple FOSS projects (both small and large), totaling over 5MLOC. They found over 1,300 error-handling failures, equivalent to an average defect rate of roughly one per 4,000 lines of code.

Edit 1.5: For the benefit of those who wouldn't know a KLOC from a jelly doughnut, 5 million lines of code is equivalent to several centuries worth of development effort. Why does this matter? Because the Law of Large Numbers bestows a strong presumption of representativeness on any sample that large. Sampling error is always theoretically possible, but any such claim would have to be supported by extraordinary evidence.

Edit the Second: Extrapolating the research results to systemd as a rough, order-of-magnitude estimate supports an inference of several dozen similar points of failure within systemd. ("Supposed incidence" indeed.)

Edit #2.5: The estimate of "several dozen" actually gives systemd authors the benefit of a doubt to which they are almost certainly not entitled: that they are as conscientious as an average FOSS dev about error handling. In point of fact, most of the code in systemd comes from two developers who historically treat error handling as an unnecessary annoyance, or view it someone else's job. Not QFT, but it wouldn't be at all surprising, statistically speaking, if systemd contained over 100 exception-handling failures.

Edit the Third (and hopefully last): For the benefit of non-programmers, it's important to realize that exception handling is the single most crucial element in creating robust, trustworthy, crash-resistant code. In practice, less than half of production-quality code is devoted to its intended function; the rest is devoted to error prevention and handling.

Edit IV (long after the fact): It's worth acknowledging that not all exception-handling errors are created equal. Some are relatively benign, while others are potentially catastrophic. But it's important to realize that malicious intent is not required for code to be destructive; sloppiness is more than adequate to bork a system, particularly in operationally critical code.


It's sad, almost pathetic, that what started off as a funny, light-hearted attempt to use code comments to make accessible to nontechnical users some of the sloppiness in systemd has degenerated into yet another thread recycling the same old arguments and the same old fallacies from systemd apologists.

Now, to minimize my self-loathing, I leave this thread to the attentions of others.
Last edited by dasein on 2015-07-26 15:23, edited 7 times in total.

User avatar
mor
Posts: 970
Joined: 2010-08-28 15:16
Location: mor@debian

Re: From the systemd source code

#20 Post by mor »

dasein wrote:
mor wrote:By the way, do you have a word or two for my question?
I do: straw man.
It would have been interesting to see whether tomazzi would have read in my question the same malice that you read in it.
But now it is not possible anymore, isn't it?

Anyway, it is interesting for me to see how you have absolutely no interest in understanding what I am saying and it is definitely not about the length of my posts.
You have your preconceived opinion of what I am saying, you have your own unshakable moral certitude that you have it all figured out and nothing can make you see beyond what you want to see.

It doesn't matter anyway because, you said it:
dasein wrote:Now, to minimize my self-loathing, I leave this thread to the attentions of others.
It would serve no purpose trying to explain or argue.

I'm happy to hear from you though.

Bye

Post Reply