From the systemd source code

Here you can discuss every aspect of Debian. Note: not for support requests!

From the systemd source code

Postby bdtc1 » 2015-07-21 10:56

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.
bdtc1
 
Posts: 25
Joined: 2015-01-22 09:00

Re: From the systemd source code

Postby spacex » 2015-07-21 17:57

ROFL. At least that's a funny take on it :lol:
spacex
 
Posts: 633
Joined: 2015-01-17 01:27

Re: From the systemd source code

Postby tomazzi » 2015-07-21 20:54

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
tomazzi
 
Posts: 730
Joined: 2013-08-02 21:33

Re: From the systemd source code

Postby NkfzGx3ok » 2015-07-21 21:12

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?
User avatar
NkfzGx3ok
 
Posts: 20
Joined: 2014-10-30 12:08

Re: From the systemd source code

Postby tomazzi » 2015-07-21 21:55

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
tomazzi
 
Posts: 730
Joined: 2013-08-02 21:33

Re: From the systemd source code

Postby somebodyelse » 2015-07-22 04:43

Make sure you file bug reports for any bugs discovered. Cold hard facts and data are your friends.
somebodyelse
 
Posts: 231
Joined: 2015-05-24 17:15

Re: From the systemd source code

Postby tomazzi » 2015-07-22 05:37

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
tomazzi
 
Posts: 730
Joined: 2013-08-02 21:33

Re: From the systemd source code

Postby somebodyelse » 2015-07-22 06:55

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.
somebodyelse
 
Posts: 231
Joined: 2015-05-24 17:15

Re: From the systemd source code

Postby thanatos_incarnate » 2015-07-22 07:54

somebodyelse wrote:filing bug reports

It's a religious war, not productive critique.
User avatar
thanatos_incarnate
 
Posts: 717
Joined: 2012-11-04 20:36

Re: From the systemd source code

Postby WeLoveDebian » 2015-07-22 08:02

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 shit 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.
WeLoveDebian
 
Posts: 98
Joined: 2014-03-16 23:00

Re: From the systemd source code

Postby keithpeter » 2015-07-22 09:59

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
keithpeter
 
Posts: 501
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: From the systemd source code

Postby NkfzGx3ok » 2015-07-22 12:12

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)
User avatar
NkfzGx3ok
 
Posts: 20
Joined: 2014-10-30 12:08

Re: From the systemd source code

Postby tomazzi » 2015-07-22 13:39

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
tomazzi
 
Posts: 730
Joined: 2013-08-02 21:33

Re: From the systemd source code

Postby mor » 2015-07-22 17:11

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
User avatar
mor
 
Posts: 969
Joined: 2010-08-28 15:16
Location: mor@debian

Re: From the systemd source code

Postby millpond » 2015-07-22 17:30

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.
millpond
 
Posts: 582
Joined: 2014-06-25 04:56

Next

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 5 guests

fashionable