Random shut down: fake power button events

Hi, I have been suffering ramdom shut downs, anywhere between 5min and 2h uptime.

Logs seem to show that there was short power button press, though this was not done physically. I have turned off all power management features to ensure they are not causing this. I have also installed sensor widget and can see CPU remains around 29 deg C, case is 19 deg C. Very cool and collected.



/var/log/cron:
Dec  8 13:01:01 localhost CROND[37321]: (root) CMD (run-parts /etc/cron.hourly)
Dec  8 13:01:01 localhost run-parts[37321]: (/etc/cron.hourly) starting 0anacron
Dec  8 13:01:01 localhost run-parts[37321]: (/etc/cron.hourly) finished 0anacron
Dec  8 13:01:01 localhost CROND[37320]: (root) CMDEND (run-parts /etc/cron.hourly)
Dec  8 13:34:12 localhost crond[1221]: (CRON) INFO (Shutting down)
Dec  8 13:35:29 localhost crond[1224]: (CRON) STARTUP (1.5.7)
Dec  8 13:35:29 localhost crond[1224]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 75% if used.)
Dec  8 13:35:29 localhost crond[1224]: (CRON) INFO (running with inotify support)
Dec  8 13:38:25 localhost crond[1224]: (CRON) INFO (Shutting down)
Dec  8 13:39:59 localhost crond[1230]: (CRON) STARTUP (1.5.7)
Dec  8 13:39:59 localhost crond[1230]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 25% if used.)
Dec  8 13:39:59 localhost crond[1230]: (CRON) INFO (running with inotify support)

/var/log/messages:

Dec  8 13:36:00 localhost rtkit-daemon[950]: Successfully made thread 2360 of process 2037 (/usr/lib64/firefox/firefox) owned by '1000' RT at priority 10.
Dec  8 13:36:00 localhost systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Dec  8 13:36:00 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm>
Dec  8 13:36:08 localhost systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Dec  8 13:36:08 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="system>
Dec  8 13:36:08 localhost audit: BPF prog-id=66 op=UNLOAD
Dec  8 13:36:08 localhost audit: BPF prog-id=65 op=UNLOAD
Dec  8 13:38:02 localhost rtkit-daemon[950]: Successfully made thread 2686 of process 2384 (/usr/lib64/firefox/firefox) owned by '1000' RT at priority 10.
Dec  8 13:38:06 localhost systemd[1273]: Starting grub-boot-success.service - Mark boot as successful...
Dec  8 13:38:06 localhost systemd[1273]: Finished grub-boot-success.service - Mark boot as successful.
Dec  8 13:38:25 localhost systemd-logind[954]: Power key pressed short.
Dec  8 13:38:25 localhost systemd-logind[954]: Powering Off...
Dec  8 13:38:25 localhost systemd-logind[954]: System is powering down.
Dec  8 13:38:25 localhost sddm-helper[1268]: Signal received: SIGTERM
Dec  8 13:38:25 localhost systemd[1]: Stopping session-2.scope - Session 2 of User prof...
Dec  8 13:38:25 localhost systemd[1]: Removed slice system-configure\x2dprinter.slice - Slice /system/configure-printer.
Dec  8 13:38:25 localhost systemd[1]: Removed slice system-getty.slice - Slice /system/getty.
Dec  8 13:38:25 localhost systemd[1]: Removed slice system-modprobe.slice - Slice /system/modprobe.
Dec  8 13:38:25 localhost systemd[1]: Stopped target graphical.target - Graphical Interface.
Dec  8 13:38:25 localhost systemd[1]: Stopped target multi-user.target - Multi-User System.
Dec  8 13:38:25 localhost systemd[1]: Stopped target getty.target - Login Prompts.
Dec  8 13:38:25 localhost systemd[1]: Stopped target network-online.target - Network is Online.

This is a desktop PC running LXQT Fedora spin.

I don’t seem to be able to find out what is inserting these fake power button events.

Can anyone suggest a way to find out what is causing this?

TIA.

Hello @fredk9 ,
Welcome to :fedora: !
Is this a new PC? It could be a failing component in the power buttons debounce circuit. This does seem hardware related.

Thanks. No , pretty old chassis. Mobo a few years old. I’ve given the whole thing a good cleanout with an air line but I have not stripped out the mobo and washed it down.

If it is a real physical event , it should be possible to mask it out. I did try editing /etc/systemd/logind.conf but when I did that it just killed the session every 10s and made me log in again.

#HandlePowerKey=poweroff
HandlePowerKey=ignore

Maybe that’s not the right way to do it ??

The thing is, what does the hardware do, like what state does this put the CPU/mobo into? I guess what I’m getting at is I have built PC’s for myself and others, plus built and still build lots for industrial use cases. In some instances I have had power button/reset button/led indicators for the case have a board failure themselves (discrete component failure, in most cases the caps in the debounce circuits, sometimes the actual switch). One test would be to quickly press&release the power button to try to mimic the effect and see if that causes the same issue for you. I’m just guessing here since we don’t even know how long the signal is to the OS. Also worth noting when talking hardware is the resettable fuse in your power supply. If for instance there is a short happening somewhere or a ground is not bonded correctly with the Mobo, this can cause problems with the power supply that can be sometimes hard to find. Finally, to make sure you’re covering all bases, clean the power button and reset button with contact cleaner with the Plug disconnected not just Power OFF, really hose it down then let it dry completely and try again. I know for a fact that the power supplies are pretty hardy, and have witnessed AT 286 PC’s still running their task in industrial uses, just one year ago at a fish farm. This is a PC from the late 1980’s.
[Edit] Sorry I just saw you cleaned it already, air pressure is fine but it won’t get rid of everything if it’s crud in the switch actuator. Though I’m still leaning on the short at the moment since it is seemingly sporadic.