Some Thoughts On Systemd

Home » CentOS » Some Thoughts On Systemd
CentOS 14 Comments

I haven’t had any problems with systemd. However, I didn’t have any problems with sysVinit over many years.

But the only practical advantage of systemd that I’ve seen touted is that it speeds up boot-time. Even if this were true it does not seem to me worth worrying about, as – in my case at least – the frequency of re-booting is so low that even if it took twice as long it would still be a negligible fraction of my time.

In fact I’ve been running CentOS-6.5 and CentOS-7 off and on for the last few days, and I have found no difference in boot-time. It takes my HP MicroServer 80 seconds to reboot and login, and at least 65 seconds of this is taken up with messages from HP’s BIOS, checking USB devices or ports, checking PXE devices (I know I could probably turn this off), and starting up KDE.

So I find this particular argument for systemd null and void.

As far as I can see, the other reason for favouring systemd is more philosophical, and is based on the idea that the many different start-up routines share a considerable amount of common code, and that it is good to take out this code and put it in a separate process. That seems to me a good Unix-like argument.

In principle this should simplify the algorithms involved. But it seems to me that the way in which it has been implemented has in fact increased the complication rather than the reverse.

14 thoughts on - Some Thoughts On Systemd

  • It is if you manage a large cluster of virtual containers which dynamically boot or shut down based on load or other factors. If you need to boot 100 virtual containers right away, boot time will be a huge factor. (Not suggesting that systemd actually solves this issue, only that boot time is important in some use cases.)

    –keith

  • If the only practical advantage of systemd that you have seen touted has been boot time efficiency then you have been poorly served by your advisors. For servers I think some of the largest advantages is that now you have a standard, built-in way to make your services highly available, both with explicit watchdog heartbeats and with automatic restarting on failure if you want, but not mindless restarting if the service is broken, you have a configurable hold down timer as well. Another advantage is in not needing to demonize anymore, which is a little song and dance of UNIX trivia I

  • Well, *something* is making EL7 boot a lot faster than EL6. My EL6 test VM takes almost twice as long to boot to a console login (runlevel 3) as my EL7 test VM. If you extract the BIOS and GRUB time as fixed constants, it probably *is* twice as fast.

    The advantages of Docker will swamp this benefit for the massive VM
    rollout case you mention, but for me and my little squad of test VMs, I’m happy to have the faster restarts.

  • Mark Tinberg wrote:

    I did not say that boot-time is touted as the only advantage of systemd. I explicitly said

    As far as I can see, the other reason for favouring systemd
    is more philosophical, and is based on the idea
    that the many different start-up routines
    share a considerable amount of common code,
    and that it is good to take out this code
    and put it in a separate process.
    That seems to me a good Unix-like argument.

    It seems to me that the arguments you put forward fall into this category. And I added the remark

    In principle this should simplify the algorithms involved.
    But it seems to me that the way in which it has been implemented
    has in fact increased the complication rather than the reverse.

    a point that you have not answered.

  • So simple things are trivial, more complicated things are possible and the options are there in the config file if you want to use them but you aren

  • But it does force people who should be focusing on improving an application to instead spend their time reconfiguring the startup configuration for a distribution just to keep it working the same way.

    For example: http://issues.opennms.org/browse/NMS-6137

    And, while it might offer a benefit in terms of being able to make it wait for the supporting postgres database if it is local, what happens if it is configured that way but you use the setup recommended for scaling where the database runs on a different system?

    —
    Les Mikesell
    lesmikesell@gmail.com

  • This seems (again) to be moving into a debate on “why systemd”, when at least for CentOS 7 the decision has been made–it’s systemd or bust (or a SIG for removing it). Perhaps we should focus systemd discussions more on how we as CentOS users can easily adjust? (I know, I already violated this principle in the thread, but I will aim not to in the future.)

    IOW, if people really don’t like systemd, I don’t think this is a good forum for that discussion.

    –keith

  • It is actually funny how there seems to be so many opponents of systemd who want back the old ways of doing things. Even the grumpy sysadmins at university I work are happier with it than the old sysv init. It really makes their work easier.

    And I have written sysv startup scripts before and I will be looking forward to convert them to systemd when my client upgrades to CentOS7 or RHEL7 depending on the machines. It seems more reasonable way of doing them and will also help in the task by automating many of the tasks which you specifically needed to take care yourself in the script before.

    And for those who complain the new way is badly written, have you actually read those old scripts like old network service and can you easily understand what is going on. When reading them I could really understand why they were abandoned for something which promises to do things simpler and more sane way. Especially as they probably should be rewritten for the new ip tools instead of the old stuff.

    But I don’t mind you complaining it makes entertaining read on the summer work trips as local free newspaper is on summer vacation. Especially when I know that the things will not change back to old sysv way. There might be something new in future, but somehow I feel that there will be new group of people complaining that why change as systemd is good enough for them.

    -vpk

  • These are the causes:-

    1. Familiarity with something that works and can be modified without much effort- very important consideration in the computer world.

    2. “Conservative” because new software is renown for creating “time wasting” frustration and irritation and sometimes “breakdowns”.

    3. Adherer to the principle “If it is working, do not repair or replace it”.

    4. Lack of knowledge about the replacement.

    The systemd files do look like Windoze .ini files.

    —
    Regards,

    Paul. England, EU.

    CentOS, Exim, Apache, Libre Office.
    Linux is the future. Micro$oft is the past.

  • Well .. all of that may be true and systemd may be the devil … but we would still have it as CentOS-7 rebuilds RHEL-7 sources. Debating whether or not systemd is a good idea is not relevant for CentOS. It is upstream, it is default, therefore it will be installed. That’s just how it is.

    We just had a bazillion mail thread on systemd and how it is terrible, we don’t need any more.

    If you want to see systemd taken out of CentOS … then figure out how to take it out.

  • NOTE: That post was not specifically at “Always Learning” .. that just happened to be the mail in this thread I was reading at the time.

  • I favour the increased knowledge of what it does and how to use it. Surely that is what the CentOS Wiki is for ?

  • Yes it is, feel free to put all your learning about systems into improving the wiki also.