SysV, Upstart, systemd as Debian / Ubuntu rake assortment

    Do you know what I'm doing now? I am writing startup scripts for systemd, and it infuriates me.

    It seems to be how we take the operating system in order to save time on such things. It seems like the packages were supposed to make our life easier. It is possible that my choice of operating system was poor, but until today I was quite comfortable living in the Debian / Ubuntu area.

    On the other hand, “was” is a convention. We are all often in relative ignorance of how our operating system works. And once you see the code / usr / sbin / service, you can no longer see it. As well as using this tool.

    Probably need to go back. To understand how we ended up in such an ass with a mixture of SysV and systemd flavored with Upstart.

    TL DR :The author whines about the zoo from SysV, Upstart and systemd on modern Debian / Ubuntu distributions.

    Sysv


    It would seem that could be easier? In the /etc/init.d/ directory there is a file with the name of the service, it is responsible for starting and stopping. We do /etc/init.d/service stop or /etc/init.d/service start and everything works fine.

    The operating system does the same, only depending on runlevel, two - so two, I will sequentially execute symlinks from /etc/rc2.d, which essentially lead to /etc/init.d, life is simple and beautiful. To control the sequence, just change the sorting of files using a number. There are utilities to automate the creation of these symlinks.

    Why couldn't we stay in that place? Because systems have changed. They became, um, complicated.

    Firstly, the state of the system was previously almost monolithic, but today it can be volatile. Bach - and connected a network adapter via USB. Under Thompson, this was not! It is necessary to respond, i.e. notify the service about it, restart someone, start someone, pay off someone.

    Secondly, SysV was deeply spit on the intimate life of programs. He started them at the start, but if you didn’t succeed, then it was your personal problems. Debugging such things, by the way, is almost impossible. Segmentation fault? Real men write programs that run the first time and do not segfoltat, wimp.

    Thirdly, the dependency structure in SysV was quite simple, which was not always enough.

    Fourth, the start of the system could not be parallel. Running scripts was strictly consistent. This is easy to see if you look at the start time of OpenSUSE, for example, shaggy version 12.

    True, the main feature of SysV was not only simplicity. With simplicity, problems came. For example, if I have every start or stop script run, then how do I know if a program is running or not? After all, she needs to send the kill signal, but without the PID there is nowhere to send it.

    It was a fresh idea to store this figure in a .pid file, quite seriously, fresh for its distant years. However, what if the program crashed with a segmentation fault? Briefly: nothing, PID must be checked before using.

    Upstart


    It seems to me that the problems started right here. That is, with how the community adopted Upstart. This set a further tone. But in order.

    Upstart supported events. He could monitor and restart programs. He knew how to build addictions. Well, with parallelism, he, too, was all right.

    In addition to one huge barrel of tar, which I will discuss further, I do not really remember any claims to Upstart. But the barrel was that the software developers generally ignored it.

    Why? I dont know. Most likely because SysV compatibility was a priority for Upstart. Therefore, the developers did not need to change anything.

    As a result, despite the fact that Upstart reigned in Ubuntu for 5 years from 2009 to 2014, a huge amount of software did not transfer to it!

    On the one hand, I cannot blame only the developers on this. They, after all, write programs. How best to run these programs on the system is none of their business. However, they write scripts for SysV. Want some examples? See what postfix startup script on Debian looks like. This code is monstrous, it's terrible, it's just scary.

    However, even worse is that many administrators do not see or understand the difference at all. They write:

    sudo service apache2 start

    And they firmly believe that apache2 should start. Argh, he shouldn't. Do you understand? Should not. The / usr / bin / service utility will start, which will begin to guess with terrible force how to start this service, and then it will transfer your request to SysV or Upstart. If you can guess correctly, yeah.

    service is not part of the Upstart package at all. It is not from there at all, but somehow coexists in this fun circle. To increase the amount of hell, some developers make /etc/init.d scripts link to Upstart. A kind of ouroboros, so that if suddenly the administrator leaves the forest and writes in Ubuntu 16.04 LTS

    /etc/init.d/service restart

    For everything to work.

    Separately, it should be said about PID. Upstart does not need the PID in the file. Why? Because any process launched by him remains his child. If he suddenly flies out, then Upstart will know about it. And since the start and stop commands also pass through it, then there is no problem.

    However, what about services that need a fork? Well, first you need to ask them why they need this? After all, in general, fork was used mainly in order to come up with the process that started them, but in the case of Upstart there is no need to do this. If init died for us, then we have a bit more problems than a broken postfix.

    But what is already there, now that 16.04 LTS is already here, what do you think, with what help does Apache2 start? postfix? Anything else? Sysv.

    True, in 16.04 systemd helps them.

    systemd


    All in all, I like systemd, honestly. His logic is much more pleasant to me than the one that Upstart had. True, if Debian had not taken the 215 release, but 218, then it would have been better to live, but to hell with it, we would survive without the edit command, if necessary.

    And systemd can be blamed for a long time, but this is already standard. However, what do you think developers do with systemd? Mostly ignored.

    So what did systemd bring in? Generators! Thousands of them!

    Briefly, if Upstart did not show off, but simply repeated the behavior of SysV, then systemd does not drop to this. It takes the existing /etc/init.d/service and based on it generates a script for systemd. It then launches.

    ExecStart=/etc/init.d/service start
    ExecStop=/etc/init.d/service stop

    Well, as it were, that's about how it turns out. I will not talk about the fact that this does not always work as it should. Rather, it starts to start. Do not try to rely on the restart of such a service in any production, monitoring will become your best alarm clock.

    And yes, you understand that systemd all the more does not need a PID, but alas. In the community, this is still not completely understood.

    To developers


    Yes guys, I agree, once again, starting a program is not your concern. However, who, if not you, knows better how to design a trouble-free start? After all, it is one thing if the start command looks like this:

    ExecStart=/usr/bin/control-bin start

    And quite another, if so:

    ExecStart=/usr/sbin/postfwd2 --file=/etc/postfwd/postfwd.cf --interface=127.0.0.1 --port=10040 --shortlog --summary=600 --cache=600 --cache-rbl-timeout=3600 --cleanup-requests=1200 --cleanup-rbls=1800 --cleanup-rates=1200 --user=postfwd --group=postfwd

    Let's stop already smearing the settings between /etc/config.conf and / etc / default / service?

    Let's stop trying to control the start of a service using the START = yes parameter in / etc / default / service? No, I understand that “xyes” looks like a great joke, but I'm tired of it already!

    Let's decide that systemd is everywhere. And that you can safely adapt to it.

    To myself


    Humble yourself, rag, and not noah. Keep calm and systemd.

    Also popular now: