Ok, thanks, now I know the output. But did it start as a foreground or as a background process, cause I have touched both option… Or is only the last option chosen activated? And how could it be deactivated?
It’s the last selection only. The active selection is shown at the top of the dietpi-autostart menu. You can deactivate it by selecting option 0 again (default, console login).
1 Like
Thank you! But meanwhile the situation has escalated.
The socket communication runs (so the dietpi can communicate via socket to the server and vice versa), so it turns on the DietPi and opens a socket communication and communcates.
Because of a failure on client sider (don’t know if as foreground or background process) , it is not able to be pinged or ssh (No DHCP or TCP/IP??). An external monitor boots and shows only a mariadb error (for what do we need Maria??), and then goes sleeping. So even no terminal comes up…The last Step of my succssful communication should be a shutdown now command, but I commented it out, so the system is at the moment just turned off during the middle of nothing,
Please what can I do, other then setting up a new dietpi image, which will take a lot of work!!!
EDIT: Now the php-7.3fpm (or similar, was very fast on the screeen) service is not starting up as well as maria db…but the socket communication still works!
you would need to check all failing services on their logs to find out what happen with them
Probably MariaDB has been installed as part of some other software stack you selected. Do you use something like nextcloud?
journalctl -u mariadb
1 Like
Did. But actually I have to solve the problem, that the board is getting back its Ip and so that I can log in. Neither via ssh nor via USB Terminal/Monitor I can connect. Only socket communication makes it simple ping pong and ends (successfully, but the rsnapshot.sh had an issue (wrong shebang), I want to fix).
Looks like it hangs on boot, respectively doesn’t finish boot. No output on HDMI?
1 Like
Lucky enough, I bought today a sd card reader with usb 3.0. I plugged in an old image of raspberry pi and was able to mount my “defect” card into the micro sd card reader. Then I chose to
$vim /var/lib/dietpi/dietpi-autostart/custom.sh
I commented out my two lines and luckily everything works well. I mean there have been a lot of cold shut downs of my devices without properly powering off with some proper shutdown scripts. Never I faced any issues with the pis.
So it was me (respectively my faulty rsnapshot configuration) causing the mariadb failure and it was me producing the python issue…
@MichaIng No the logs weren’t helping here. But if did not have such luck, how would be the best approach in terms of saving time???
Suspicion of root cause: rsnapshot uses pathes to rsync from a remote computer. I guess either the source or the destination path weren’t correct… Tip on the desitination path. It did not exist on the system. … That was the one thing I forgot before last successful reboot…
I wonder how an rsnapshot call can freeze a system like that, but running it from console once to assure it does what it’s supposed to do is airways a good idea 
.
1 Like
@MichaIng Of course! It was running on the synology! 
And I was too impatient…obviously…so I have setup the wrong backup pathes…but that is only a guess. I corrected it, and I have a subsequent error:
The error you edited out has gone? Looks like the log directory did not exist.
1 Like
Another guess! Does anybody know about side issues, when I connect to early to ssh, during boot?
For me there is an incredibly measurable diff between my two pis, the one is booting up in a few seconds, while this one here needs half a minute or more to log in to…
Not really, if the SSH server is not yet up, the connection simply fails, if the network is not yet up, you wouldn’t be able to connect either, of course. Some services may start later, but nothing I can think of which would be required for console usage.
Main reasons I can think of is the time for network bring up, e.g. if DHCP is used or USB adapters vs onboard ones, WiFi vs Ethernet, and the time for drives to be mounted, e.g. USB drives vs internal drives, SD cards or eMMC modules. You could queck journalctl to see the order and time it took for each systemd service and target to be reached, before the SSH server is started.
1 Like
Or , right after a fresh reboot, you could run systemd-analyze blame to see where the time is gone.
2 Likes
I cannot prove it, but I am pretty sure (for my pi here), If I ssh to the system during boot before it is “ready” for it, it probably did not catch an ip, but it will surely have problems in connecting via ssh. Only solution then is reboot…
@Joulinar I will definitely check against systemd-analyze blame to find the cause, 'cause this can cause nearly the same behaviour as well…
[EDIT]: Here is the result:
# systemd-analyze blame
8.591s ifup@wlan0.service
6.354s ifup@eth0.service
2.881s mariadb.service
1.280s ifupdown-pre.service
1.234s dev-mmcblk0p2.device
1.127s xrdp.service
1.013s phpsessionclean.service
692ms rpi-eeprom-update.service
438ms php7.3-fpm.service
392ms lighttpd.service
347ms mono-xsp4.service
315ms dietpi-ramlog.service
303ms systemd-fsck@dev-disk-by\x2dpartuuid-907af7d0\x2d01.service
294ms wpa_supplicant.service
279ms systemd-logind.service
278ms redis-server.service
273ms dietpi-preboot.service
262ms networking.service
237ms keyboard-setup.service
235ms systemd-udev-trigger.service
234ms user@0.service
138ms systemd-journald.service
134ms ssh.service
131ms systemd-fsck-root.service
109ms fake-hwclock.service
97ms systemd-remount-fs.service
93ms systemd-udevd.service
72ms systemd-timesyncd.service
71ms systemd-tmpfiles-setup.service
66ms systemd-sysctl.service
59ms dev-mqueue.mount
58ms rng-tools.service
53ms xrdp-sesman.service
49ms alsa-restore.service
48ms boot.mount
45ms systemd-tmpfiles-setup-dev.service
44ms sys-kernel-debug.mount
41ms avahi-daemon.service
40ms systemd-modules-load.service
40ms systemd-user-sessions.service
38ms systemd-update-utmp-runlevel.service
34ms systemd-sysusers.service
34ms systemd-journal-flush.service
33ms kmod-static-nodes.service
32ms systemd-update-utmp.service
32ms user-runtime-dir@0.service
30ms systemd-random-seed.service
23ms systemd-rfkill.service
17ms console-setup.service
11ms tmp.mount
10ms sys-kernel-config.mount
9ms var-log.mount
It looks very similar to my other Pi:
# systemd-analyze blame
8.683s ifup@wlan0.service
4.963s ifup@eth0.service
2.616s tor@default.service
2.118s coturn.service
1.923s ifupdown-pre.service
1.552s rpimonitor.service
1.356s proftpd.service
1.306s nmbd.service
1.268s mariadb.service
1.123s nfs-server.service
1.089s xrdp.service
941ms dev-mmcblk0p2.device
822ms php7.3-fpm.service
750ms upower.service
643ms rpi-eeprom-update.service
510ms smbd.service
377ms systemd-fsck@dev-disk-by\x2dpartuuid-8f4dbd00\x2d01.service
253ms phpsessionclean.service
251ms polkit.service
237ms systemd-udev-trigger.service
229ms user@0.service
217ms networking.service
216ms lighttpd.service
214ms mono-xsp4.service
213ms keyboard-setup.service
182ms ssh.service
177ms rpcbind.service
175ms xrdp-sesman.service
172ms dietpi-ramlog.service
168ms dietpi-preboot.service
158ms systemd-logind.service
156ms nextCloud.mount
154ms systemd-journald.service
152ms systemd-fsck-root.service
141ms redis-server.service
112ms systemd-remount-fs.service
108ms systemd-rfkill.service
101ms boot.mount
89ms nfs-mountd.service
69ms systemd-timesyncd.service
68ms systemd-udevd.service
65ms systemd-tmpfiles-setup.service
63ms systemd-modules-load.service
54ms proc-fs-nfsd.mount
48ms systemd-journal-flush.service
48ms systemd-tmpfiles-setup-dev.service
But I had to wait for a few minutes (I do not know the exact time, but it is definitely higher than 1 minute) before I could log in. It is both Raspberry Pi 4b with 4GB/8GB (first via second mentioned)…
According to the log, I should be able to do this after 30 s as I supposed.
[EDIT2]:
Sorry, now the reboot was working exactly like it should, I am really confused…so I could log in exactly after 30 s…
Welcome to Murphy’s Law
1 Like
journalctl could give some more details, e.g. the output of the services, including ifup, DHCP lease progress, SSH startup etc.
Btw, it is intended that Ethernet and WiFi are both enabled? Since I see no hostapd, they do not seem to be WiFi hotspots? If network ranges are not clearly separated, or a bridge set up, this might cause network issues.
Terrific! I will fix that!
We can close this case - at least for me!