Well, it still continues to crash :(
The Hard Solution
Since it continues to crash I initially thought it could be a problem related to the power supply, maybe someone changed the wires configuration and forgot to re-plug correctly all the wires related to my server. But I couldn't find anything wrong with the cables.
After months of this problem, I decided to do a proper deep investigation. I checked the reboot history with last -x and noticed a very suspicious pattern:
shutdown system down 6.8.0-90-generic Wed Feb 11 21:41 - 09:11 (11+11:30)
shutdown system down 6.8.0-90-generic Tue Feb 10 17:59 - 19:34 (1+01:35)
shutdown system down 6.8.0-90-generic Wed Jan 21 08:37 - 15:50 (20+07:12)
shutdown system down 6.8.0-90-generic Sun Jan 18 21:05 - 06:27 (2+09:22)
shutdown system down 6.8.0-90-generic Sat Jan 17 12:25 - 18:53 (1+06:27)
Every single time, the server ran for approximately 2 hours before shutting down. This was not a coincidence.
The Investigation
I searched for what triggered the shutdown:
journalctl -b -1 | grep -i "power\|systemctl\|initiated"
And there it was:
feb 11 21:41:02 mosearcserver systemd-logind[958]: The system will power off now!
feb 11 21:41:02 mosearcserver systemd-logind[958]: System is powering down.
Again systemd-logind! The same culprit from the previous chapter. But I already checked logind.conf and both IdleAction and HandleLidSwitch were set to ignore. So logind wasn't deciding on its own... something was telling it to shut down.
I also noticed something interesting in the boot logs:
feb 11 19:35:13 mosearcserver systemd[1]: logrotate.service was skipped because of an unmet condition check (ConditionACPower=true).
feb 11 19:56:33 mosearcserver systemd[1]: apt-daily-upgrade.service was skipped because of an unmet condition check (ConditionACPower=true).
Services that require AC power were being skipped. The system thought it was running on battery!
The Root Cause: UPower + Damaged Battery
I ran upower -d and everything became clear:
Daemon:
on-battery: no
critical-action: PowerOff
The critical-action is set to PowerOff. Since this is an old laptop with a damaged battery, here's what was happening:
- The old battery reports unreliable charge levels to the system.
- At some point (after ~2 hours), the damaged battery reports a critically low level.
- UPower sees critical battery → tells
systemd-logindto perform an emergency power off. - The server shuts down gracefully, even though it's plugged into AC power and running fine.
The ~2 hour timing was the damaged battery slowly reporting lower and lower values until it hit the critical threshold. The safety mechanism designed to protect against data loss was being triggered by a broken sensor!
The Fix
Two things I did:
1. Software fix: I edited /etc/UPower/UPower.conf and changed:
CriticalPowerAction=PowerOff
to:
CriticalPowerAction=Ignore
Then restarted the service:
sudo systemctl restart upower
This tells UPower: "Even if you think the battery is critical, do nothing."
2. Hardware fix: I physically removed the damaged battery from the laptop. Since the server runs entirely on AC power, the battery was only causing problems. Without it, UPower has nothing to misread.
Lesson Learned
Sometimes the safety mechanism that's supposed to protect your server is the thing that keeps killing it. A damaged battery on a laptop-server is worse than no battery at all — it actively lies to the OS about its charge level and triggers false emergency shutdowns. If you're running a server on laptop hardware, either make sure the battery is healthy or remove it and set CriticalPowerAction=Ignore.
Update: Seems working, the server is not crashing anymore
Next Steps:
- Containerization of everything
- Uninterruptible Power Supply
- Firewall/VLANs/DMZ
- Notification System to inform me of everything appening
- Implement a Self Hosted Dirve (w NAS)
- Mail Server
- Local LLM (if the hardware permits it)