phantomfive's Journal: systemd 12 - how large is pid 1?

Systemd pid 1 takes up 1.5 megabytes on my Fedora system hard drive. For comparison, sysvinit compiles down to 40k. For security purposes, smaller is better, but getting the interfaces right is far more important.

So what is systemd doing with that 1.5 megabytes of compiled code? To answer that question, we find a good place to start, src/core/main.c, which is 2085 lines long. That is not necessarily too long, but if you are a fan of short functions, you will be horrified to learn that the main function is 825 lines long.

Typically a long function starts out well organized, but as people add to it over time, it becomes more and more chaotic, and that is starting to happen here. It is not always clear the order of why things happen, for example. If I were going to refactor this, it would look something like this:

main() {
    init();
    main_loop();
    cleanup();
}

So what is it doing with all those 825 lines of code? I went through and made a rough outline, which I wrote in code form. It could be further simplified, of course, but this will give you a basic understanding of what is in the main function, and it's better than 825 lines of chaotic code:

int main(void) {
 
  getTimestamp();
  parseSomeCommandlineArgs();
  setPIDNameToSystemd();
  setUMaskToZeroIfRequired();
 
  initFilesystems();
  initSELinux();
  initSMACK();
  initIMA();
  initKernelClocks();
  initLogging();
 
  initDefaultUnit();
  initJoinControllers();
 
  mountKernelVirtualFilesystems();
  initSignalHandlers();
  parse_Config_Commandline_Environment_and_KernelCommandLine();
  daemonize();
 
  initIfRunningAsManagerSystem();
  initIfRunningAsManagerUser();
  managerSetup();
 
  setCapabilityBounding();
  enforceSyscallArchitectures();
 
  queueDefaultJob();
 
  do{
      runMainLoop();
  }while(handleStateChange());
 
  reexecuteIfNeeded();
 
  cleanupAndShutdown();
}

I tried pasting the original function here so you could compare, but Slashdot apparently doesn't allow posts that long and chopped it off. If you want to see it, you'll have to put some extra effort in and click on this link.

When code gets too long, you need to break it into smaller pieces, so the human brain can see how the code is organized. When you refactor like this, it's important to make sure that the refactored code shows the overall structure, rather than obscuring it.

As always, please comment or correct me below, I am interested in hearing what you think!
(I've written other reviews, too, check them out).

Is this actually a problem?

[AmiMoJo]

Sometimes refactoring just makes it harder to follow the code with no real benefit. This is particularity true of linear functions with little or no logic/branching.

I think you need to show some specific problems rather than general points.

Re:

[phantomfive]

Have you actually looked at the systemd code I linked to, or are you just guessing what it looks like?

Re:

[AmiMoJo]

Yep, I looked. It's not great but I think your idea wouldn't really improve it either.

Having said that, rather than just complaining about it why don't you just refactor it and submit a patch?

Re:

[phantomfive]

Having said that, rather than just complaining about it why don't you just refactor it and submit a patch?

If even you don't think it's an improvement, then why do you think they will accept a patch?
There aren't many people who appreciate when you tell them you've found a better way to write their code.

Re:

[AmiMoJo]

Why do you think they wouldn't accept it? That's how open source software works. If you haven't tried it you can't really complain that they will reject your patch.

Just don't sabotage it with language. Submit it as a simple clean up/readability improvement.

Re:

[phantomfive]

Why do you think they wouldn't accept it?

Again, for the same reason you don't like it: people who think 800 line functions are a good idea will not accept that they are wrong.
Here in this conversation, I am not going to be able to convince you that you are wrong......you would argue until you got tired of it that 800 line function are a good idea.

I think your opinion is wrong-headed, personally, but beauty is in the eye of the beholder. It's your opinion, and you are free to write code however you wish.

Re:

[ookaze]

Why do you think they wouldn't accept it?

Again, for the same reason you don't like it: people who think 800 line functions are a good idea will not accept that they are wrong.

Here in this conversation, I am not going to be able to convince you that you are wrong......you would argue until you got tired of it that 800 line function are a good idea.

tl;dr: this has already been discussed and justified by systemd devs, and what you see is the result.

I'm surprised to see these kind of discussions about systemd here.
Actually I'm not anymore. I've come to expect that people critical of systemd always have a take like systemd devs are incompetent morons.
That's why they always end up being months if not years behind the systemd devs in thinking about Linux plumbing.
That leads to stupid waste of time like uselessd, when the far more competent systemd devs too

Re:

[phantomfive]

I can attest that the patch would be rejected, as eveything said here was already discussed on the ML or elsewhere

Link please, or GTFO.

Re:

[tibit]

Why functions calling are not always a good thing with a plumbing program like systemd PID 1 has already been discussed and explanations given on the ML.

Either you're making shit up, or whoever made that argument had a moronic moment. There's no reason whatsoever to make the code less comprehensible to humans, even on a process with PID 1.

Re:

[tibit]

There aren't many people who appreciate when you tell them you've found a better way to write their code.

?! I'd love it.

Re:

[phantomfive]

You are an awesome person, I like you.
Also, I like your sig: "A successful API design takes a mixture of software design and pedagogy."

Re:

[tibit]

I spend a significant amount of effort on writing better code. If someone could figure it out faster and/or better, and wanted to just tell me, I'd be utterly stupid not to listen and learn. What's not to love? But yeah, many developers have personalities that are not very amenable to such input. I'm superbly aware that a lot of what I do could be done better. The key issue is balancing self-improvement and progress in product development. Input from others lets me get the products out faster and/or learn t

Re:

[phantomfive]

ok, I modified the journal entry based on your comment. I tried actually posting the original code for comparison, but Slashdot rejected it lol.
So now I have a better post, thanks to your input. "Open Source" methods ftw!

Good work

[fnj]

Thank you for your thoughtful entries on systemd.

My impression of FreeBSD's init/rc system is positive, mostly due to everybody playing by the same boilerplate, so not every single daemon reinvents the same scriptage wheels, as happens on sysvinit in linux. The other big superiority with FreeBSD is the absence of symlinking bash to sh. It has a real standardized POSIX sh guaranteed to be there in every installation, and people actually write to its API, rather than putting /bin/sh in the shebang line but th

Re:

[Eunuchswear]

he other big superiority with FreeBSD is the absence of symlinking bash to sh.

Debian fixed that a few years ago.