Dear Debian community, I hit the similar problem but this time with /run folder. Few services have failed to start:
# systemctl status php7.0-fpm.service Jun 24 23:09:48 debian php-fpm7.0[893]: [24-Jun-2020 23:09:48] ERROR: unable to bind listening socket for address '/run/php/php7.0-fpm.sock': No such file or directory (2) Jun 24 23:09:48 debian php-fpm7.0[893]: [24-Jun-2020 23:09:48] ERROR: FPM initialization failed Jun 24 23:09:48 debian systemd[1]: php7.0-fpm.service: Main process exited, code=exited, status=78/CONFIG Jun 24 23:09:48 debian systemd[1]: php7.0-fpm.service: Failed with result 'exit-code'. Jun 24 23:09:48 debian systemd[1]: Failed to start The PHP 7.0 FastCGI Process Manager. # systemctl status motioneye.service Jun 24 23:09:47 debian systemd[1]: Started motionEye Server. Jun 24 23:09:48 debian meyectl[895]: INFO: hello! this is motionEye server 0.41 Jun 24 23:09:48 debian meyectl[895]: CRITICAL: pid directory "/run/motioneye" does not exist or is not writable Jun 24 23:09:48 debian systemd[1]: motioneye.service: Main process exited, code=exited, status=255/EXCEPTION Jun 24 23:09:48 debian systemd[1]: motioneye.service: Failed with result 'exit-code'. # cat /etc/tmpfiles.d/php.conf d /run/php/sessions 1733 root root # cat /etc/tmpfiles.d/motioneye.conf d /run/motioneye 0750 motion motion Just after the boot I have inspected /run folder. It was created/mounted correctly and there have been a lot of files/directories there. I suspect that all services that have created the necessary directory under /run were able to start normally. Few of them which relied on existence of specific directory, have failed to started. After I have replayed the corresponding instructions for tmpfiles.d, the services have started normally. I have a feeling that systemd-tmpfiles was executed before /run was mounted. Needless to note that the problem is not persistent: sometimes OS boots without a single failed service. How can I debug the problem? Thank you! On 2020-05-18 02:39, Dmitry Katsubo wrote: > On 2020-05-11 20:11, Darac Marjal wrote: >> On 11/05/2020 08:40, Reco wrote: >>> Hi. >>> >>> On Mon, May 11, 2020 at 09:33:59AM +0200, Dmitry Katsubo wrote: >>> >>>> root@debian:~ # systemctl status binfmt-support >>>> * binfmt-support.service - Enable support for additional executable >>>> binary formats >>>> Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; >>>> vendor preset: enabled) >>>> Active: failed (Result: exit-code) since Sun 2020-05-10 21:54:27 CEST; >>>> 10h ago >>>> Docs: man:update-binfmts(8) >>>> Process: 353 ExecStart=/usr/sbin/update-binfmts --enable (code=exited, >>>> status=2) >>>> Main PID: 353 (code=exited, status=2) >>>> >>>> May 10 21:54:27 debian update-binfmts[353]: update-binfmts: unable to open >>>> /var/lib/binfmts: No such file or directory >>>> >>>> Any help is appreciated. >>> This should help your problem: >>> >>> mkdir /etc/systemd/system/binfmt-support.service.d >>> >>> cat > /etc/systemd/system/binfmt-support.service.d/override.conf << EOF >>> [Unit] >>> RequiresMountsFor=/var >>> EOF >> >> As another alternative, one can run "systemctl edit >> binfmt-support.service", which will create the intervening folders and >> files for you, and reload the daemon if the editor exits with success. > > Thanks for suggestion! I have tried the advise and it actually worked > (I will keep an eye on that because one reboot may not be representative). > I wonder nevertheless what is the problem with this specific unit? It has > dependency on local-fs.target which in turn should mount /var. So what > exactly went wrong? -- With best regards, Dmitry
