Debian 10服务器运行12小时后自动关机问题求助

Hey Sven, let's tackle this frustrating 12-hour auto-shutdown issue on your Debian 10 e-commerce server. Since you've already ruled out most hardware (except the original drive) and basic system logs show no obvious errors at shutdown time, here's a structured troubleshooting plan to narrow down the root cause:

Auto-shutdowns often boil down to a hidden scheduled job—let's rule this out first:

• Cron jobs: Run these commands to check all user crontabs for shutdown/reboot commands timed around the 12-hour mark:

  sudo crontab -u root -l
  for user in $(cut -f1 -d: /etc/passwd); do echo "=== $user ==="; crontab -u $user -l; done
  

• Systemd timers: List all active and inactive timers to see if any trigger a shutdown service:

  sudo systemctl list-timers --all
  

  For any suspicious timers, inspect their details with sudo systemctl status <timer-name>.timer.
• At jobs: Check for one-time scheduled tasks with sudo atq—these can sometimes fly under the radar.

Debian's power-saving features or BIOS/UEFI settings might be triggering the shutdown, even without log errors:

• ACPI settings: Monitor ACPI events in real-time with sudo acpi_listen, and check /etc/default/acpi-support for any shutdown-related configurations.
• Systemd-logind: Look at /etc/systemd/logind.conf for parameters like IdleAction or IdleActionSec—even for an e-commerce server, if there's a lull in traffic, misconfigured idle settings could trigger a shutdown.
• BIOS/UEFI power options: Reboot into your server's BIOS/UEFI and double-check for settings like "auto-shutdown after X hours" or power-saving modes that might be enabled (even with new hardware, these settings can persist or reset to defaults).

Since you kept the original drive, disk-related issues could be the culprit:

• Filesystem errors: Run a read-only filesystem check (to avoid disrupting the server) with:

  sudo fsck -n /dev/<your-root-partition>
  

  For a thorough check, boot from a live Debian CD and run fsck on the unmounted partition. Also, check /var/log/fsck/ for past filesystem check logs.
• Disk health: Use S.M.A.R.T. tools to check for drive degradation:

  sudo smartctl -a /dev/<your-drive>
  

  Look for attributes like Reallocated_Sector_Ct, Current_Pending_Sector, or Offline_Uncorrectable—these indicate failing hardware that might cause unexpected shutdowns.
• Disk space & swap: Run df -h to ensure no partitions are full (especially / or /var—full disks can cause odd system behavior) and free -h to check if swap is exhausted. Severe memory pressure might trigger a shutdown on some systems.

Your e-commerce platform or related services might be accidentally triggering the shutdown:

• Application logs: Dig into logs for your web server (/var/log/nginx/ or /var/log/apache2/), database (e.g., /var/log/mysql/), and your e-commerce application itself. Look for any scripts or processes that execute shutdown commands.
• Process monitoring: Set up a simple cron job to log process stats every hour, so you can spot resource hogs that might destabilize the system:

  # Add this to root's crontab with sudo crontab -e
  0 * * * * ps aux >> /var/log/process_monitor.log
  

• Third-party tools: If you use backup scripts, monitoring agents, or custom automation tools, verify none of them have a 12-hour shutdown trigger built in.

Even if kern.log shows no shutdown-time errors, a hidden kernel issue might manifest after 12 hours:

• Verbose kernel logging: Edit /etc/default/grub and change GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" to GRUB_CMDLINE_LINUX_DEFAULT="debug", then run sudo update-grub and reboot. This generates more detailed kernel logs that might capture the shutdown trigger.
• Kernel modules: List loaded modules with lsmod and check for any power-management or hardware-related modules that might be misbehaving. Try updating or temporarily unloading suspicious modules.
• Test a different kernel: Install a newer kernel from Debian backports (if available) to rule out bugs in your current kernel version.

Less likely, but worth eliminating:

• Firewall & SSH logs: Check /var/log/ufw.log (or iptables logs) and /var/log/auth.log for any unauthorized access attempts or incoming connections that might send a shutdown signal.
• Remote management tools: If you use IPMI, cloud provider management consoles, or remote monitoring tools, verify there are no automated shutdown rules set for 12 hours of uptime.

If all else fails, strip down the system to isolate the issue:

• Boot into multi-user mode: Run sudo systemctl set-default multi-user.target and reboot—this starts the system without graphical interfaces and non-essential services. Monitor if it still shuts down after 12 hours.
• Disable non-essential services: Turn off services like your web server, database, and e-commerce platform one by one. Re-enable them individually to identify which service might be causing the problem.

内容的提问来源于stack exchange，提问作者Sven