Investigating Random System Shutdowns on Linux Mint Cinnamon: A Deep Dive

We understand the frustration that arises when a system behaves erratically, especially when the cause is elusive. Experiencing unexpected shutdowns on your Linux Mint Cinnamon laptop, particularly when you’re actively engaged or even idle, can be a perplexing issue. This is precisely the scenario we aim to diagnose and resolve here at revWhiteShadow, going beyond the surface-level symptoms to uncover the root cause. You’ve reported a pattern of your Lenovo IdeaPad 5 2-in-1 14AHP9 randomly shutting down, with system logs indicating a self-initiated shutdown. This, despite your assurance that you are not interacting with the power button or any shutdown-related prompts. Let’s meticulously dissect this problem and explore potential solutions.

Understanding the Symptoms: Beyond Thermal and RAM Concerns

Your initial assessment correctly rules out common culprits like overheating and excessive RAM usage. With CPU temperatures well below critical thresholds (around 39.7°C) and RAM utilization not exceeding 40%, and a substantial, largely unused swap file, these typical system instability factors are unlikely to be the direct cause. This suggests a more nuanced issue, perhaps related to system event handling, power management, or even an unusual hardware interaction within your Linux Mint Cinnamon environment. The fact that the issue persists across both X11 and Wayland display servers further narrows down the possibilities, pointing away from display-specific driver conflicts.

The critical piece of information you’ve provided is from journalctl --boot=-1 priority=3, which indicates an intentional shutdown. The discrepancy lies in the system logging these events when you are demonstrably not performing such actions. This could imply an unintended trigger being interpreted as a manual shutdown command.

Deconstructing the journalctl Output: A Closer Look

The journalctl logs are your primary window into the system’s recent activity, especially concerning shutdowns. When the system reports a shutdown initiated by the user, it often correlates with specific system events or signals. The pastebin link you shared, while not directly accessible to us, would typically contain messages related to system power state changes, user logins/logouts, or potentially kernel-level power management events. Understanding these messages in detail is paramount.

Even if the logs show a user-initiated shutdown, the context is crucial. If you were engaged in an activity like gaming with a PS5 controller, or even setting up a USB drive, and the system logs this as a shutdown, it suggests an underlying mechanism is misinterpreting an input or event as a shutdown command.

The Enigma of the Unintended Power Button Signal

Your description of the system logging an event where you’re “reaching for my power button, and invisibly clicking on ‘shut down’” is particularly telling. This implies that an event, seemingly unrelated to physical power button interaction, is being translated into a shutdown signal. This could originate from several sources:

  • Input Device Misinterpretation: While you’re using a PS5 controller, other input devices could be sending spurious signals. Even a slightly malfunctioning USB device, or an unexpected interaction with the touchpad or keyboard, might generate a sequence of events that the system interprets as a shutdown command.
  • ACPI Events: Advanced Configuration and Power Interface (ACPI) events are the system’s way of handling hardware states, including power button presses, lid closures, and battery events. While you’ve tried ACPI_Listen without observing anything out of the ordinary, ACPI events can be complex and sometimes subtle. It’s possible a specific ACPI event is being triggered, perhaps related to power states or even a false positive from a thermal sensor (though your thermal readings are good).
  • Kernel Power Management Modules: The Linux kernel has sophisticated power management subsystems. Sometimes, these can misinterpret certain hardware states or receive conflicting signals, leading to unexpected behavior.
  • Software Bugs or Conflicts: A bug in a specific application or a background service could be inadvertently sending shutdown signals. This is particularly relevant if the shutdowns correlate with the use of specific software.
  • Hardware Malfunction (Subtle): While not overtly thermal or RAM related, a subtle hardware issue, perhaps with the motherboard’s power management circuitry or even a faulty sensor that’s not being reported as out-of-spec, could be the culprit.

Lid Status and its Potential Implications

Your check on the lid status using upower -d | grep lid showed lid-is-closed: no and lid-is-present: yes. This is standard behavior for a laptop that is open and in use. However, it’s worth considering if any unusual interactions with the lid sensor, or a misinterpretation of the lid state by the system, could indirectly trigger power events. For instance, if the system briefly thought the lid was closed and then reopened, it might initiate certain power state transitions.

Systematic Troubleshooting: A Path to Resolution

Given the information, we need to adopt a systematic approach to pinpoint the exact cause of these random shutdowns. This involves a combination of enhanced logging, careful observation, and targeted testing.

Enhanced Logging and Event Monitoring

To catch these elusive events, we need to increase the verbosity of system logging and monitor specific event queues.

Detailed journalctl Analysis and Persistent Logging

While journalctl --boot=-1 priority=3 gives you the immediate post-shutdown picture, it’s beneficial to configure the system for persistent logging so that you can examine events leading up to the shutdown more comprehensively.

  1. Enable Persistent Logging: Ensure systemd-journald is configured to store logs persistently. You can check the configuration in /etc/systemd/journald.conf. Uncommenting or setting Storage=persistent is the standard way. This ensures logs are not lost on reboot.
  2. Monitor Live Logs: Before engaging in activities that tend to trigger the shutdowns, open a terminal and run:
    journalctl -fk --priority=3
    This command will continuously display kernel messages with a priority of 3 (errors) and above, and will also show messages from other system daemons. It’s crucial to have this running in a visible terminal window when you suspect a shutdown might occur. Look for any unusual messages immediately preceding the shutdown.
  3. Capture Specific Event Streams: You might need to monitor specific event queues related to power management and input events.

Monitoring ACPI Events More Closely

Your previous attempt with ACPI_Listen may have been too brief or didn’t capture the specific type of ACPI event.

  1. acpi_listen with Verbosity: While acpi_listen is a command-line tool, its output can be quite raw. If it didn’t yield anything, consider using more advanced debugging tools if available within your kernel or distribution.
  2. Kernel Module Parameters: Some ACPI-related kernel modules might have debug parameters that can be loaded or modified. This is a more advanced step and requires identifying the specific ACPI drivers in use for your Lenovo IdeaPad 5.
  3. evtest for Input Events: The evtest utility can be invaluable for monitoring raw input events from all connected input devices, including keyboards, mice, touchpads, and game controllers.
    • Installation: You might need to install it: sudo apt install evtest
    • Usage: Run sudo evtest and select the input device you suspect might be causing issues (e.g., your PS5 controller if it’s listed, or even the internal keyboard/touchpad). Monitor the output carefully for any unexpected or repeated events that coincide with the shutdown.

Power Management Event Logging with upower and systemd-logind

upower and systemd-logind are key components of Linux power management.

  1. upower -w: This command can watch for power events. Run upower -w in a terminal and observe its output when the shutdown occurs.
  2. systemd-analyze blame and systemd-analyze critical-chain: While these are for boot times, they can give you insights into what services are running and could potentially be involved in power management.
  3. loginctl for Session and Power Events: The loginctl command can also provide information about user sessions and system power states. loginctl show-session <session_id> might reveal details, though it’s less likely to directly pinpoint a spurious shutdown trigger.

Investigating Input Device Interactions

The presence of your PS5 controller and the possibility of interactions with other input devices warrants a closer look.

Isolating the PS5 Controller’s Influence

Since you’re gaming, the controller is a prime suspect for generating unintended input.

  1. Test Without the Controller: Perform a test where you completely disconnect the PS5 controller and do not use it for an extended period. If the shutdowns cease, you’ve found your culprit. Then, the focus shifts to configuring or troubleshooting the controller’s driver or its input mapping.
  2. Controller Configuration Tools: Linux has various tools for configuring game controllers, such as jstest-gtk or using xboxdrv (which can often be adapted for PlayStation controllers). Ensure its configuration isn’t generating phantom button presses or axis movements that might be mapped to a shutdown function.
  3. Check for Button Mapping Conflicts: It’s possible a combination of button presses on the controller, or a specific input sequence, is being interpreted by the system or a background service as a shutdown command.

Disabling Other Input Devices (Temporarily)

If the controller isn’t the issue, consider temporarily disabling other input devices to see if that makes a difference.

  1. Touchpad and Keyboard: While less likely to cause a “power button” event directly, a malfunctioning touchpad could generate spurious clicks or gestures. You can temporarily disable the touchpad via your system settings or using xinput if you’re on X11.
  2. USB Devices: Disconnect all non-essential USB devices, including your PS5 controller (if not the primary suspect), external drives, webcams, etc. Test if the problem persists with only the bare minimum peripherals connected.

Power Management Settings and ACPI Configuration

Linux Mint Cinnamon, like most desktop environments, relies on underlying power management daemons and ACPI.

Examining dconf Settings (for Cinnamon)

Cinnamon’s power management settings are often controlled via dconf. While direct command-line manipulation might be complex, understanding what these settings control is useful.

  1. GUI Power Settings: First, go through the System Settings -> Power Management in Cinnamon. Ensure there are no unusual settings for “When power button is pressed” or “When laptop lid is closed” that might be misfiring.
  2. dconf-editor (Advanced): If you’re comfortable with it, you can use dconf-editor (install with sudo apt install dconf-editor) to browse the settings under /org/gnome/settings-daemon/plugins/power/. Look for any options that seem unusual, but proceed with caution as incorrect changes can affect system behavior.

Systemd- logind.conf and Power Button Behavior

The logind.conf file often defines how the system handles power button presses and lid events.

  1. Edit logind.conf: Open the file /etc/systemd/logind.conf with administrative privileges:
    sudo nano /etc/systemd/logind.conf
  2. Check Relevant Directives: Look for lines like:
    • HandlePowerKey=
    • HandleSuspendKey=
    • HandleHibernateKey=
    • HandleLidSwitch=
    • HandleLidSwitchExternalPower=
    • HandleLidSwitchDocked= By default, HandlePowerKey=poweroff is common. If this is set to something unusual, or if there are other directives that could be misinterpreted, you might consider changing them temporarily. For instance, to prevent the power key from doing anything, you could set HandlePowerKey=ignore. Remember to uncomment the line by removing the # at the beginning.
  3. Apply Changes: After saving the file, restart the systemd-logind service:
    sudo systemctl restart systemd-logind
    Then reboot your system to ensure the changes are fully applied.

BIOS/UEFI Settings

While you haven’t mentioned any recent BIOS updates or changes, it’s always worth a quick check.

  1. Power Management Options: Enter your laptop’s BIOS/UEFI settings (usually by pressing F2, F10, F12, or Del during boot). Look for any advanced power management options, wake-on-LAN settings, or ACPI behaviors that might be configured in a way that could cause unexpected power cycles. Ensure these are set to their defaults or standard configurations.

Software and Driver Considerations

Even though you’ve ruled out obvious RAM and thermal issues, software interactions can be intricate.

Kernel Modules and Drivers

The specific hardware in your Lenovo IdeaPad 5 2-in-1 14AHP9 will have associated kernel modules.

  1. Graphics Drivers: While you’re on X11 and Wayland, ensuring your graphics drivers (likely Intel integrated graphics for an IdeaPad 5) are up-to-date and correctly installed is always good practice. Sometimes, graphics driver issues can manifest in strange system behaviors.
  2. Input Drivers: Ensure all input device drivers are functioning correctly.
  3. Power Management Drivers: Check for any specific kernel modules related to your laptop’s power management or ACPI implementation. You can often see loaded modules with lsmod. Identifying which ones might be relevant requires knowing your specific hardware components.

Background Services and Startup Applications

A rogue background service or a startup application could be the culprit.

  1. Identify Startup Applications: Use the “Startup Applications” tool in Linux Mint to review any programs that launch automatically. Temporarily disable non-essential ones and see if the shutdowns continue.
  2. Systemd Services: Use systemctl list-units --type=service --state=running to see what services are actively running. If you notice any unusual services or services related to power management or input handling that you don’t recognize, further investigation might be needed.

Hardware Diagnostics (Last Resort)

If all software and configuration checks fail, it might point to a more subtle hardware issue.

  1. Memory Test: Although RAM usage isn’t high, a faulty RAM module can cause intermittent issues. Running a memory test like Memtest86+ (often available from your Linux Mint bootable USB) is a good idea.
  2. Disk Health: While less likely to cause shutdown events logged as user-initiated, checking the health of your SSD or HDD using smartctl (install with sudo apt install smartmontools) is a good general diagnostic step.
  3. Battery Health: If the battery is very old or faulty, it could potentially cause power delivery issues, though typically this would manifest as sudden power loss rather than a logged shutdown. You can check battery health with upower -i /org/freedesktop/UPower/devices/battery__BAT0 (replace __BAT0 if your battery is named differently).

Conclusion: A Path Forward

The phenomenon of your Linux Mint Cinnamon system randomly shutting down, with logs indicating an intentional shutdown when you’re not the one initiating it, is a complex troubleshooting challenge. We’ve outlined a comprehensive strategy involving:

  • Deepening our understanding of journalctl and other system logs.
  • Systematically isolating input devices, particularly your PS5 controller.
  • Scrutinizing power management configurations in both the desktop environment and systemd.
  • Considering kernel module and driver interactions.
  • Reviewing startup applications and background services.

By methodically working through these steps, you should be able to identify the specific trigger for these disruptive shutdowns. Remember to make changes one at a time and test thoroughly between each modification. This persistent and detailed approach is key to resolving even the most baffling system anomalies, ensuring your Linux Mint experience is as stable and reliable as it should be. We are confident that by carefully following these investigative pathways, you will be able to restore the stability of your Lenovo IdeaPad 5.