Part 1: The Red Herring (I was being hacked!)

While I was digging through the system logs to figure out why my server crashed during the file transfer (see previous post), I stumbled upon something terrifying. It turns out the crash wasn't the only thing happening. Someone was trying to brute-force my server.

Here is a snippet of what I found in the logs:

dic 20 09:44:43 mosearcserver sshd[1188239]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=91.202.233.33  user=root
dic 20 09:44:45 mosearcserver sshd[1188239]: Failed password for root from 91.202.233.33 port 33810 ssh2
dic 20 09:44:49 mosearcserver sshd[1188265]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=91.202.233.33  user=root
dic 20 09:45:04 mosearcserver sshd[1188341]: Failed password for root from 91.202.233.33 port 30068 ssh2

Someone from IP 91.202.233.33 was hammering my server, trying to guess the root password. After a quick lookup, that IP is a known malicious address associated with brute-force attacks.

The Security Fix

Even though this likely didn't cause the crash, it was a massive security hole. I immediately took the following steps:

  1. Disable Root Login: I edited /etc/ssh/sshd_config and set:
    PermitRootLogin no
  2. Firewall Block: I banned the attacker's IP:
    sudo ufw deny from 91.202.233.33
  3. Hardening: To be 100% sure, I removed the allow rule for standard SSH port 22 and moved SSH to a custom port.
    sudo ufw delete allow 22/tcp

Part 2: The Real Crash (The Idle Freeze)

With the intruders locked out, I went back to the original problem. Why did the server crash? The logs ended with a "whisper" rather than a scream—no error codes, just silence.

Investigating the Reboot History

I ran last -x reboot | head -n 5 and saw this:

reboot   system boot  6.8.0-90-generic Fri Dec 26 10:45   still running
reboot   system boot  6.8.0-86-generic Mon Nov 17 20:36   still running
reboot   system boot  6.8.0-86-generic Mon Nov 17 20:29 - 20:35  (00:05)

Checking Resources

I suspected a memory leak or CPU overload, but sar told a different story:

  • RAM: sar -r ... showed only 5% usage.
  • CPU: sar -u ... showed 99% Idle.
  • Hardware Logs: dmesg showed no thermal or hardware errors.

The Verdict: It died of boredom

It turns out my server crashed because it was too idle. This is a known phenomenon called "The Idle Freeze", especially common when running Linux servers on laptop hardware (which I am doing).

When the CPU does absolutely nothing (99% idle), it tries to enter a deep power-saving mode (C-State). On some hardware, the kernel fails to wake the CPU back up from this deep sleep, causing the system to freeze instantly.

The Solution

Since I cannot change the hardware, I had to tell the Linux kernel: "Don't let the CPU sleep too deeply."

Step 1: Modify GRUB

I edited /etc/default/grub and added the following flags to limit the C-States:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash modprobe.blacklist=nouveau processor.max_cstate=1 intel_idle.max_cstate=1"

(I also blacklisted Nouveau since I don't need the graphics driver on a headless server).

Step 2: Mask Sleep Targets

To ensure the laptop never tries to "Suspend to RAM" (which also causes crashes on servers), I ran:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

This combination (C-State fix + Disable Sleep) is the gold standard for running Linux on laptop hardware. Since applying this fix, the uptime has been rock solid!