Why doesn't php7.2-fpm start after reboot?

Question

PHP

service php7.2-fpm status
● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Sun 2018-01-28 05:08:57 +05; 1min 36s ago
Docs: man:php-fpm7.2(8)
Process: 434 ExecStart=/usr/sbin/php-fpm7.2 --nodaemonize --fpm-config /etc/php/7.2/fpm/php-fpm .conf (code=killed, signal=TERM)
Main PID: 434 (code=killed, signal=TERM)
Jan 28 05:07:26 vm-83a6fe5c systemd[1]: Starting The PHP 7.2 FastCGI Process Manager...
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: php7.2-fpm.service: Start operation timed out. Terminating.
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: Failed to start The PHP 7.2 FastCGI Process Manager.
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: php7.2-fpm.service: Unit entered failed state.
Jan 28 05:08:57 vm-83a6fe5c systemd[1]: php7.2-fpm.service: Failed with result 'timeout'.

Answer 1

Alexander Vladimirovich , let's explain, since it's not only you who have such a thing, as I see in the comments.
To understand the reason, we add to the call to start the service tracking it through strace with writing a log to a file. To do this, just add the full path to this utility and a set of keys to the service start line, for example:
Actually, any application can be debugged this way. After the reboot, we look at the file we specified in order to understand what broke.
Run command breaks on getrandom request. If you set a delay in the start of the process, then this request is processed. At the same time, the further to postpone the start of the service, the faster it works.
This call is directly related to the random/urandom system calls and the amount of entropy in the system. Obviously, the work of system calls should not change from the start time, although it is worth checking the start sequence of services in systemd. So this is entropy.
At the start, we look at the quantity
and we get a peppy zero at the time of the first getrandom request, which is the reason for the failure. Entropy grows slowly, and the web server needs it to perform cryptographic functions. In the set timeout, the call does not have time to collect the required number of random data due to low entropy. As a solution, you can use the haveged package. Moreover, we decided to add it to our image by default and the problem will no longer occur on new virtual servers in the near future.
An excerpt from an article on entropy:

Linux already provides pretty good random data with the above software, but since standalone computers usually don't have a keyboard or mouse, the entropy generated on them is much lower, since it's generated by disk or network I/O. Very few autonomous machines have dedicated RNG hardware, so there are several custom solutions for generating extra entropy with hardware interrupts, as some devices (such as sound and video cards) create more so-called "noise" than a hard drive. Unfortunately, even this does not solve the problem of virtual servers, because there is practically nothing to generate entropy. But this is where the haveged tool comes to the rescue. Based on the HAVEGE algorithm (and earlier on its library), haveged allows you to generate random data,

Answer 2

Something is wrong with the configuration, most likely.
Try running /usr/sbin/php-fpm7.2 --nodaemonize --fpm-config /etc/php/7.2/fpm/php-fpm.conf from the console and see what it complains about.

Answer 3

As a temporary solution, I added the line
TimeoutSec =600 to /lib/systemd/system/php7.2-fpm.service Starts after a minute and 44 seconds. Maybe there will be a better solution later. UPD The problem was solved with the help of Netangels technical support, by installing the haveged package.