Randomly can't SSH into my DietPi install but can ping

Troubleshooting
1

Since a few days ago, I randomly can’t SSH into my DietPi for some reason.

The day before this happened, everything was fine. Then the next day, while nothing was changed, I couldn’t SSH in. It doesn’t time out or error out, it literally just stays on a black screen with the rectangular cursor. I can’t even see the log in prompt. I have tried Putty but it’s the same problem.

When I ping the device, it responds, the pings are sometimes quite high 100ms+, sometimes normal 10ms. Never shows any packet loss.

The device, Raspberry Pi Zero W, is connected to my router, assigned a static IP by the router. On the router status page, it shows the device is connected and working.

The problem is completely gone if I unplug the Pi then plug it back in. But it would work for maybe 2 days before the same problem happens again.

How do I go about troubleshooting this problem?
Is it hardware-related?

Raspberry Pi Zero W

DietPi v9.14

Only thing I have on it:
Unbound
AdGuard Home
OpenSSH Client

All settings are default.

Thanks.

2

Without logs, error messages or a connected screen, it is quite difficult to find out what is happening. One option would be to activate permanent logs. This should make it possible to see what the last activities were before the system stopped working.

persistent system logs:

dietpi-software uninstall 103 # uninstalls DIetPi-RAMlog
mkdir /var/log/journal # triggers systemd-journald logs to disk
reboot # required to finalise the RAMlog uninstall

Then you can check system logs via:

journalctl

which will then show as well logs from previous boot sessions. To limit the size, you can additionally e.g. apply the following:

mkdir -p /etc/systemd/journald.conf.d
cat << '_EOF_' > /etc/systemd/journald.conf.d/99-custom.conf
[Journal]
SystemMaxFiles=2
MaxFileSec=7day
_EOF_

This will limit logs to 14 days split across two journal files, so that with rotation you will always have between 7 and 14 days of logs available.

3

Thank you, just did those.

After I uninstalled RAMlog and did the reboot.
It immediately went dead. Couldn’t log in.
So I had to power cycle the device.

Then after I logged in after the power cycle and checked the system logs.
First warning I see is

Jun 30 18:12:18 DietPi systemd-fsck[133]: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.

the last couple lines before the power cycle say

Jun 30 18:12:51 DietPi dropbear[385]: [385] Jun 30 18:12:51 Failed loading /etc/dropbear/dropbear_rsa_host_key
Jun 30 18:12:51 DietPi dropbear[385]: [385] Jun 30 18:12:51 Failed loading /etc/dropbear/dropbear_dss_host_key

Then I did the 2nd part limiting the log size. Then rebooted again.

Then I checked the logs again

some permission warnings on AdGuard Home?

Jun 30 18:39:35 DietPi AdGuardHome[327]: 2025/06/30 18:39:35.221372 [info] permcheck: warning: found unexpected permissions type=directory path=/mnt/dietpi_userdata/adguardhome perm=0777 want=0700
Jun 30 18:39:35 DietPi AdGuardHome[327]: 2025/06/30 18:39:35.221873 [info] permcheck: warning: found unexpected permissions type=directory path=/mnt/dietpi_userdata/adguardhome/data perm=0755 want=0700
Jun 30 18:39:35 DietPi AdGuardHome[327]: 2025/06/30 18:39:35.222247 [info] permcheck: warning: found unexpected permissions type=directory path=/mnt/dietpi_userdata/adguardhome/data/filters perm=0755 want=0700
Jun 30 18:39:35 DietPi AdGuardHome[327]: 2025/06/30 18:39:35.222592 [info] permcheck: warning: found unexpected permissions type=file path=/mnt/dietpi_userdata/adguardhome/data/sessions.db perm=0644 want=0600
Jun 30 18:39:35 DietPi AdGuardHome[327]: 2025/06/30 18:39:35.223343 [info] permcheck: warning: found unexpected permissions type=file path=/mnt/dietpi_userdata/adguardhome/data/stats.db perm=0644 want=0600

And the same two errors from before show up repeatedly

Jun 30 18:45:30 DietPi dropbear[712]: [712] Jun 30 18:45:30 Failed loading /etc/dropbear/dropbear_rsa_host_key
Jun 30 18:45:30 DietPi dropbear[712]: [712] Jun 30 18:45:30 Failed loading /etc/dropbear/dropbear_dss_host_key

I checked the logs on another device with same setup and it doesn’t have any

Failed loading /etc/dropbear/dropbear_rsa_host_key

something wrong with Dropbear?

Since this last reboot, so far it’s working ok. Ping is under 1ms like normal.

4

This is certainly due to the unclean shutdown

Furthermore, the Dropbear and AGH messages are unrelated to the problem

5

Well this is weird.

Other than doing the above logging stuff, I also moved the Pi to a smart plug so I can power cycle it easily.

But then this problem stopped, for over 2 weeks, until today (July 20).

Around 19:30 I noticed I couldn’t open AdGuard Home in my browser anymore.
Try to SSH into the Pi, no response.
Ping the device, no packet loss, response time around 10ms.

Power cycled and checked the logs.

Jul 20 18:17:02 DietPi kernel: Booting Linux on physical CPU 0x0

It seems the device lost power around 18:17.
I also see the “dirty bit” warning confirming an unclean shutdown.

But I didn’t do anything and don’t have any scheduled reboot/shutdowns.
Maybe the socket is bad and it lost power.

But, the logs after the boot-up all look fine.
Networking service started no error.
Unbound service started no error.
AdGuard service started no error.
etc.
Other than the previously mentioned Dropbear “failed loading key” errors, there are no other errors.
Yet I couldn’t log into the device…
I don’t understand.
Think I might just format and reinstall the entire system later…

6

that’s a wrong interpretation of this time stamp. DietPi saves a current time once an hour. This is used during a reboot in order to have an approximate time. It is always saved at the 17th minute of the hour.

In your case, you would have to say that the system got stuck between 18:17 and 19:17.

Have you already activated persistent logs?

7

When ever I see this and as a precaution I like to take the file system off line, boot from a live linux and check/repair all the file systems.

8

Yes, I did what you said in the 2nd post. I was checking log with journalctl
Can I DM u a link with the log?

9

yes sure, you can attach it as well as txt file to your post or load it to Pastebin

10 
Jul 20 18:17:01 DietPi CRON[17622]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Jul 20 18:17:01 DietPi CRON[17623]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jul 20 18:17:01 DietPi CRON[17622]: pam_unix(cron:session): session closed for user root
-- Boot ee2c287698c142f789876fbb595d485a --
Jul 20 18:17:02 DietPi kernel: Booting Linux on physical CPU 0x0
Jul 20 18:17:02 DietPi kernel: Linux version 6.12.25+rpt-rpi-v6 (serge@raspberrypi.com) (arm-linux-gnueabihf-gcc-12 (Raspbian 12.2.0-14+rpi1) 12.2.0, GNU ld (GNU Binutils for Raspbian) 2.40) #1 Raspbian 1:6.12.25-1+rpt1 (2025-04-30)
Jul 20 18:17:02 DietPi kernel: CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
Jul 20 18:17:02 DietPi kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache

These are the lines before and after the crash/restart. Basically, all log entries are OK. No indication of a reason for the system crash. Here, unfortunately, we can only make assumptions like problems with the power supply or other things like kernel panic. But without an exact log entry (which we don’t have) nobody can answer that.

1 Like
11

Thank you for checking over the log. I suspect it’s a power supply thing. The power brick I’m using is some no-name thing I found lying around lol.

How do I revert the log-to-disk changes from post 2? Do I just reinstall RAMlog? Will it automatically disable log2disk?

Thanks.

edit: changed outlet it’s plugged into and no longer happened.

edit 2: re-enabled RAMlog and it started happening again randomly… it’s probably the Pi board.

12

This should be possible by going to dietpi-software and selecting the logging system of your choice.

1 Like
13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.