Running terminal commands at startup

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 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/

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 :slightly_smiling_face:.

1 Like

@MichaIng Of course! It was running on the synology! :smiley: 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.


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.

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!