Random crashes, hardware error? #4817
Comments
|
Many thanks for your report. Could you do the same monitoring of |
|
Thanks for your reply |
|
Not sure either. Is there a kernel upgrade available? apt update
apt full-upgrade |
|
The system is fully up to date. I have restarted the logging and increased the netrate limit so now ill wait for it to crash again and save the SSH output to text and post it here. I have done 12hr long memtester runs on free memory and 60min of CPU stresstesting from DietPi so I think its more SW than HW. Ill post an update when it crashes again. |
|
The cron daemon is running? systemctl status cron
# or
journalctl -u cron |
|
I mean at the time of the crash the Cronjob was not running, it is running when the system is up and running. So that is an indicate that something 'off screen' had been going wrong. Lets see what happens when it crashes again |
|
Ok, got some new crashes: CRASH dmesg output (cpu crash at end?): Logfile attached. Click to expand!CRASH Logfile attached. Click to expand! |
|
Is this by purpose to block DNS request from your network to Google DNS? |
|
Yes it is, in my router i have set requests to 8.8.8.8 and 8.8.4.4 to redirect to my pihole device to preven ChromeCast and other IOT devices from bypassing pihole. It is all very wierd behaviour. Sometimes the system runs for weeks until I manually restart it for some reason and sometimes it crashes very frequently (after few minutes, couple times a day). |
|
I always get the same dmesg errors during boot: As far as I know the EDAC messages are due to the CPU supporting ECC but not having ECC memory installed. |
|
What is the Also which CPU governor do you use? Could you try to change it, e.g. from CPU temperatures are fine? G_OBTAIN_CPU_TEMP |
|
The Governor is schedutil and temps idle are 33 degrees and under load 40-50 degrees so nothing strange there. I have a gut feeling (looking at al the posts online) it has something to do with my PHY (Realtek R8111G) since it has this strang thing that it wont reconnect automatically and seems to crash when a cable is loose. |
That won't restart the network, but only the loopback interface 😉. Did you every observe this functional? To restart the Ethernet interface, do: or the related service: But I'd be careful with such automated service restarts: When they are done during the boot sequence, this may cause issues with other services/targets depending on them. You can skip sudo when just adding that job to the root users crontab, respectively one of the |
Hmm, did not know that :). Wierd thing is, if I restart my fritzbox (that points to this server as DNS server) both my pihole and pivpn clients stay down indefinitely. The extra sudo is just an oversight :). |
Very strange, as this should only bring down and up the loopback interface, nothing more. Or is the eth0 interface defined with Probably also the loopback interface reload triggers somehow the Ethernet adapter to wake up or so. I mean usually a router restart shouldn't affect the client interface at all, but usually it is immediately usable again as fast as the physical connection has been reestablished. So there seem to be a firmware-wise layer, like a power savings or sleeping mode or so that the connection stays lost 🤔. |
|
Yes, it is very strange. If I remove the ethernet cable for a few seconds it usually is ok and restores the connection. If I wait longer (say 3-10 sec+) or plug it in to an unmanaged switch instead of directly into the Fritzbox or into another port of the Fritzbox the connection does not restore at all.
Dont know why the DNS server is in there as 127.0.0.1 to be honest, perhaps because of PiHole + Unbound. |
|
The real truth for DNS server should be |
|
Okay, makes sense then. |
|
adress is a typo indeed :) (sry, logged in on a work pc and ssh to the server from my phone so am typing stuff over). I am using unbound, so in that case why not have unbound resolve it by pointing to 127.0.0.1? |
|
E.g. Unbound might be stopped during a package upgrade, and it may then break its own network capability so that the upgrade cannot succeed. Or it may fail for any other reason and you then cannot reinstall the package because it broke its own DNS. It's like maintaining/fixing the branch you're sitting on 😉. But most importantly, is there any reason why you wouldn't want to use public DNS for the requests that server does? For ad blocking this cannot be, but if you don't want to have any public provider know that your server is contacting e.g. GitHub or dietpi.com to check for updates, or Debian/Raspbian servers for APT updates, then of course you may use Unbound (and manually change |
|
Just using Anyway what will happen if unbound or Pihole are not working? Correct you would need to adjust your local DNS server settings to be able to get back internet access in DietPi. This could be avoided by using a public DNS server directly. As well we had a couple of reports in past where Pihole was blocking some GitHub address. And there shouldn't be anything to block, as long as you don't use a web browser on DietPi. 😉 |
|
Hmm, that does make sense indeed. Never realized you would need to set an external DNS for the PiHole server. But then, this wouldnt cause these wierd crashes and the PHY not reconnecting right ;)? |
|
In the past Pi-hole actually automatically configured itself as DNS, but that got removed for exactly this reason: It usually doesn't make sense and causes more issues than benefits. As long as you know how to change it manually when Pi-hole/Unbound fails, all is fine, but usually no need to risk that situation 😉. |
|
I lost track here. Is there still an issue/question remaining? |
|
Sry bit late but no there is not. |
|
Okay great. That the Ethernet connection is not usable after a temporary router reboot is indeed strange. Probably a rare hardware specific limitation. However, good that you have a workaround. Probably we will widen the DietPi-WiFi-Monitor do be a general connectivity monitor to either restart the current connection (like it does now and your script does) or alternatively fallback to another adapter until the preferred/main adapter connectivity is up again: #3254 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Creating a bug report/issue
Required Information
I am having random crashes on my Pihole + PiVPN + Unbound system. I thought the problem was Pihole so I finally managed to log it over SSH but now I am not so sure what the problem is.
I am using a Watchdog and a Kernel Panic counter so my system reboots itself most of the times but there definately is a problem. Is this hardware related?
The text was updated successfully, but these errors were encountered: