SysV, Upstart, systemd as a Debian / Ubuntu rake assortment
Do you know what I'm doing now? I write start scripts for systemd, and it pisses me off.
It seems to be how we take the operating system in order to save time on such things. It seems like the packages should have made our lives easier. It’s quite possible that my choice of operating system was bad, but until today I was comfortable in the Debian / Ubuntu area.
On the other hand, “was” is a convention. All of us are often in relative ignorance as to how our operating system is structured. And once having seen the / usr / sbin / service code, you can no longer read it. Just like using this tool.
')
Probably need to go back. To understand how we found ourselves in such an ass with a mixture of SysV and systemd flavored with Upstart.
Tl; DR : author whines about the zoo from SysV, Upstart and systemd in modern Debian / Ubuntu distributions.
It would seem, what 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 thing, only depending on runlevel, two - so two, I will consistently execute symlinks from /etc/rc2.d, which in essence lead to /etc/init.d, life is simple and beautiful. To manage the sequence, it is enough to change the sorting of the files using a number. There are utilities to automate the creation of these symlinks.
Why couldn't we stay in that place? Because the systems have changed. They became, um, complicated.
Firstly, the state of the system was previously almost monolithic, and today it can be changeable. Bach - and connected via USB network adapter. When Thompson was not like this! It is necessary to react, i.e. notify the service of this, restart someone, start someone, redeem someone.
Secondly, SysV did not care about the intimate life of programs. He started them at the start, but if something didn’t work for you, then it was your personal problems. To debug such things, by the way, is almost impossible. Segmentation fault Real men write programs that run the first time and are not weak, weak.
Third, the dependency structure in SysV was fairly simple, which was not always enough.
Fourth, the start of the system could not be parallel. Script launch was strictly sequential. This is easy to see if you look at the start time of openSUSE, for example, the shaggy 12 version.
True, the main feature of SysV was not only simplicity. There were problems with simplicity. For example, if I have each launch of a start or stop script separate, then how do I know if the program is running or not? After all, she needs to send a kill signal, and there is no place to send it without PID.
A fresh idea was to keep this figure in the .pid file, right, well, seriously, fresh for their distant years. However, what if the program crashes with a segmentation fault? In short: nothing, the PID must be checked before using.
It seems to me that the problems started right here. That is, with how the community took upstart. This set a further tone. But in order.
Upstart supported events. He could follow and restart programs. He knew how to build dependencies. Well, with parallelism, he, too, was all right.
Except for one, a huge barrel of tar, which I will talk about further, I don’t remember any complaints about Upstart. But the barrel was that the developers of software in general ignored it.
Why? I dont know. Most likely because compatibility with SysV 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 during the period from 2009 to 2014, a huge amount of software never passed to it!
On the one hand, I can not blame only the developers. 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 examples? See what the postfix script in Debian looks like. This code is monstrous, it's terrible, it's just scary.
However, even worse is that many administrators do not see and do not understand the difference. They write:
, apache2 . , . ? . /usr/bin/service, , , SysV Upstart. , .
service Upstart. , - . , /etc/init.d Upstart. , Ubuntu 16.04 LTS
.
PID. Upstart PID . ? . , Upstart . , .
, fork? , ? , fork , , Upstart . init, , postfix.
, , 16.04 LTS , , Apache2? postfix? ? SysV.
, 16.04 systemd.
, systemd, . , Upstart. , Debian 215 , 218, , , edit, .
systemd , . , systemd? .
, systemd? ! !
, Upstart , SysV, systemd . /etc/init.d/service systemd. .
, . , , . , . - , .
, , systemd PID, . .
, , , , . , , , ? , :
, :
/etc/config.conf /etc/default/service?
START=yes /etc/default/service? , , «xyes» , !
, systemd — . .
, , . Keep calm and systemd.
It seems to be how we take the operating system in order to save time on such things. It seems like the packages should have made our lives easier. It’s quite possible that my choice of operating system was bad, but until today I was comfortable in the Debian / Ubuntu area.
On the other hand, “was” is a convention. All of us are often in relative ignorance as to how our operating system is structured. And once having seen the / usr / sbin / service code, you can no longer read it. Just like using this tool.
')
Probably need to go back. To understand how we found ourselves in such an ass with a mixture of SysV and systemd flavored with Upstart.
Tl; DR : author whines about the zoo from SysV, Upstart and systemd in modern Debian / Ubuntu distributions.
Sysv
It would seem, what 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 thing, only depending on runlevel, two - so two, I will consistently execute symlinks from /etc/rc2.d, which in essence lead to /etc/init.d, life is simple and beautiful. To manage the sequence, it is enough to change the sorting of the files using a number. There are utilities to automate the creation of these symlinks.
Why couldn't we stay in that place? Because the systems have changed. They became, um, complicated.
Firstly, the state of the system was previously almost monolithic, and today it can be changeable. Bach - and connected via USB network adapter. When Thompson was not like this! It is necessary to react, i.e. notify the service of this, restart someone, start someone, redeem someone.
Secondly, SysV did not care about the intimate life of programs. He started them at the start, but if something didn’t work for you, then it was your personal problems. To debug such things, by the way, is almost impossible. Segmentation fault Real men write programs that run the first time and are not weak, weak.
Third, the dependency structure in SysV was fairly simple, which was not always enough.
Fourth, the start of the system could not be parallel. Script launch was strictly sequential. This is easy to see if you look at the start time of openSUSE, for example, the shaggy 12 version.
True, the main feature of SysV was not only simplicity. There were problems with simplicity. For example, if I have each launch of a start or stop script separate, then how do I know if the program is running or not? After all, she needs to send a kill signal, and there is no place to send it without PID.
A fresh idea was to keep this figure in the .pid file, right, well, seriously, fresh for their distant years. However, what if the program crashes with a segmentation fault? In short: nothing, the PID must be checked before using.
Upstart
It seems to me that the problems started right here. That is, with how the community took upstart. This set a further tone. But in order.
Upstart supported events. He could follow and restart programs. He knew how to build dependencies. Well, with parallelism, he, too, was all right.
Except for one, a huge barrel of tar, which I will talk about further, I don’t remember any complaints about Upstart. But the barrel was that the developers of software in general ignored it.
Why? I dont know. Most likely because compatibility with SysV 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 during the period from 2009 to 2014, a huge amount of software never passed to it!
On the one hand, I can not blame only the developers. 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 examples? See what the postfix script in Debian looks like. This code is monstrous, it's terrible, it's just scary.
However, even worse is that many administrators do not see and do not understand the difference. They write:
sudo service apache2 start, apache2 . , . ? . /usr/bin/service, , , SysV Upstart. , .
service Upstart. , - . , /etc/init.d Upstart. , Ubuntu 16.04 LTS
/etc/init.d/service restart.
PID. Upstart PID . ? . , Upstart . , .
, fork? , ? , fork , , Upstart . init, , postfix.
, , 16.04 LTS , , Apache2? postfix? ? SysV.
, 16.04 systemd.
systemd
, systemd, . , Upstart. , Debian 215 , 218, , , edit, .
systemd , . , systemd? .
, systemd? ! !
, Upstart , SysV, systemd . /etc/init.d/service systemd. .
ExecStart=/etc/init.d/service start
ExecStop=/etc/init.d/service stop, . , , . , . - , .
, , systemd PID, . .
, , , , . , , , ? , :
ExecStart=/usr/bin/control-bin start, :
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/etc/config.conf /etc/default/service?
START=yes /etc/default/service? , , «xyes» , !
, systemd — . .
, , . Keep calm and systemd.
Source: https://habr.com/ru/post/307958/
All Articles