Services fail to start after updating to v6.33.3

Troubleshooting
21

root@pi4:~# systemctl restart systemd-tmpfiles-setup
Failed to restart systemd-tmpfiles-setup.service: Operation refused, unit systemd-tmpfiles-setup.service may be requested by dependency only (it is configured to refuse manual start/stop).
See system logs and ‘systemctl status systemd-tmpfiles-setup.service’ for details.

root@pi4:~# systemctl status systemd-tmpfiles-setup.service
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:tmpfiles.d(5)
man:systemd-tmpfiles(8)

22

ah yeah correct. The service has a setting to prevent manuell restart

RefuseManualStop=yes

MichaIng
Any ideas? Would it be ok to run the ExecStart command manually?

23

UPDATE: after a few tests, among which tried the following:

sudo apt-get install --reinstall php-fpm




sudo dietpi-software resintall lighttpd php

and a few restarts everything now seems to work.
I suppose that reinstalling damaged components recreated the missing files…

Now I have:
root@pi4:~# ls -la /run/dietpi/
total 12
drwxrwxrwx 2 root root 100 Oct 30 13:54 .
drwxr-xr-x 26 root root 860 Oct 30 13:54 …
-rw-rw---- 1 root root 1094 Oct 30 13:54 .dietpi_motd
-rw-rw-rw- 1 root root 49 Oct 30 13:54 .network
-rw-r–r-- 1 root root 2 Oct 30 13:53 .timesync_exit_status

And:
root@pi4:~# ls -la /run/php/
total 4
drwxr-xr-x 2 www-data www-data 80 Oct 30 13:53 .
drwxr-xr-x 26 root root 860 Oct 30 13:54 …
-rw-r–r-- 1 root root 3 Oct 30 13:53 php7.3-fpm.pid
srw-rw---- 1 www-data www-data 0 Oct 30 13:53 php7.3-fpm.sock
and there are no more error messages at boot… :smiley:

Thanks a lot for your support, and if I can help others with running some commands to investigate just ask!

24

well the interesting point was, why service systemd-tmpfiles-setup was failing. But I guess this is solved now as well.

25

It generally makes sense that this service is not allowed to be restarted manually. It runs the tmpfiles command with an argument to pre-create and clear as well those directories which are marked to be only safe to clear on boot. Some of them are quite important, contain PID files, sockets and state files, which are required to e.g. perform systemd journal logs or contain other runtime information. In theory the journalctl entry could be too old to still be shown. The journal may be large but it has some limits and there are other cases where it’s cleared or rotated. Best is hence to reboot and check then whether the service has run successfully or not and if all expected dirs are present. Since this was the case now, it should be fine. When a similar issue is faced again we’d need to have a closer look why some of the dirs are missing, if this was really the case after reboot or those have been removed by something afterwards.