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).
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
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?
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
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 .
@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.
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.
Or , right after a fresh reboot, you could run
systemd-analyze blame to see where the time is gone.
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 firstname.lastname@example.org 6.354s email@example.com 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 firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org 4.963s email@example.com 2.616s firstname.lastname@example.org 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 email@example.com 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.
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
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!