LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware
User Name
Password
Linux - Hardware This forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?

Notices


Reply
  Search this Thread
Old 11-12-2022, 02:25 AM   #1
BoraxMan
Member
 
Registered: Apr 2010
Posts: 103

Rep: Reputation: 11
System powers down on resume


Suspend resume used to work on my desktop system, but I use them rarely. I've found now that when I suspend the computer, it suspends just fine. The problem is, when I resume it by pressing a key on the keyboard the system wakes up, then goes through a shutdown process. It does not just turn off, it actually shutdowns as if the 'shutdown' command were issued.

So this may not be a hardware issue, but something is causing Linux to think that the power button is pressed on resume.

I'm using a custom kernel, version 6.0.3, but I tried a previous kernel, 5.18.10 and that acted the same way.

The journalctl output is as follows. The thing that interests me is the "Power Key Pressed" messages. No power key was pressed, but it seems that Linux thinks it was, hence why it is initiating the shutdown process.

Obviously, I am not wanting Linux to shutdown the system on resume.

The part of the journal which covers the time when it sleeps and resumes is below...

Nov 12 18:50:11 Penguin.Underworld kernel: random: crng reseeded on system resumption
Nov 12 18:50:11 Penguin.Underworld kernel: PM: suspend exit
Nov 12 18:50:11 Penguin.Underworld rtkit-daemon[972]: The canary thread is apparently starving. Taking action.
Nov 12 18:50:11 Penguin.Underworld systemd-resolved[920]: Clock change detected. Flushing caches.
Nov 12 18:50:11 Penguin.Underworld rtkit-daemon[972]: Demoting known real-time threads.
Nov 12 18:50:11 Penguin.Underworld systemd-sleep[1800]: System returned from sleep state.
Nov 12 18:50:11 Penguin.Underworld rtkit-daemon[972]: Successfully demoted thread 1628 of process 1622 (/usr/bin/pulseaudio).
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld rtkit-daemon[972]: Successfully demoted thread 1625 of process 1622 (/usr/bin/pulseaudio).
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld rtkit-daemon[972]: Successfully demoted thread 1622 of process 1622 (/usr/bin/pulseaudio).
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld rtkit-daemon[972]: Demoted 3 threads.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd-logind[980]: Power key pressed.
Nov 12 18:50:11 Penguin.Underworld systemd[1]: systemd-suspend.service: Deactivated successfully.
Nov 12 18:50:11 Penguin.Underworld systemd[1]: Finished System Suspend.
Nov 12 18:50:11 Penguin.Underworld audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 12 18:50:11 Penguin.Underworld audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 12 18:50:11 Penguin.Underworld systemd[1]: Stopped target Sleep.
Nov 12 18:50:11 Penguin.Underworld systemd[1]: Reached target Suspend.
Nov 12 18:50:12 Penguin.Underworld systemd[1]: Starting NVIDIA system resume actions...
Nov 12 18:50:12 Penguin.Underworld suspend[1890]: nvidia-resume.service
Nov 12 18:50:12 Penguin.Underworld systemd[1]: Stopped target Suspend.
Nov 12 18:50:12 Penguin.Underworld logger[1890]: <13>Nov 12 18:50:12 suspend: nvidia-resume.service
Nov 12 18:50:12 Penguin.Underworld systemd[1]: nvidia-resume.service: Deactivated successfully.
Nov 12 18:50:12 Penguin.Underworld systemd[1]: Finished NVIDIA system resume actions.
Nov 12 18:50:12 Penguin.Underworld audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nvidia-resume comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 12 18:50:12 Penguin.Underworld audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nvidia-resume comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 12 18:50:12 Penguin.Underworld systemd-logind[980]: Operation 'sleep' finished.
Nov 12 18:50:12 Penguin.Underworld NetworkManager[1113]: <info> [1668239412.0326] manager: sleep: wake requested (sleeping: yes enabled: yes)
Nov 12 18:50:12 Penguin.Underworld NetworkManager[1113]: <info> [1668239412.0333] device (enp3s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Nov 12 18:50:12 Penguin.Underworld udisksd[992]: Applying configuration from /etc/udisks2/ST2000DM001-1CH164-Z1E2BCQ0.conf to /dev/sdd
Nov 12 18:50:12 Penguin.Underworld udisksd[992]: Applying configuration from /etc/udisks2/WDC-WD6401AALS-00L3B2-WD-WCASY6921417.conf to /dev/sda
Nov 12 18:50:12 Penguin.Underworld udisksd[992]: Set APM level to 255 on /dev/sdd [ST2000DM001-1CH164-Z1E2BCQ0]
 
Old 11-12-2022, 05:57 AM   #2
zeebra
Senior Member
 
Registered: Dec 2011
Distribution: Slackware
Posts: 1,830
Blog Entries: 17

Rep: Reputation: 638Reputation: 638Reputation: 638Reputation: 638Reputation: 638Reputation: 638
Well, obviously it COULD be that there is an actual physical issue with your "power key". What kind of key is it anyways, where is it placed and how does it look, how is it pressed etc?

Another obvious possibility seems to be that your system interprets any keypress as the "power key" when in sleep mode. Could that be the case, and why would it do that?

Or it could be neither of those things, some sort of bug, and since the log says systemd is responsible, perhaps it could be a bug there, or perhaps it could help to look into its configuration somehow. Furthermore, if you want to look online for possible solutions, look into similar "systemd" issues. Perhaps also have a further dive into systemd logs (journald) and find all possible information, and look into as much as possible any systemd settings. UDEV is part of systemd, and I think responsible for the "power key" settings/definitions/implementations etc.

In the end, are there any other reasons the "power key" could be pressed? What exactly is the definition of "power key" on your system? Does it have several definitions? Or is it ONLY interpreted as the actual single on/off button? What kind of other "signals" could be interpreted as the "power key"?

If you can't figure it out, and you feel like going advanced to find the issue, do consider using Linux Audit to get the accurate details as to what is going on and trace the root cause.

Last edited by zeebra; 11-12-2022 at 06:01 AM.
 
Old 11-12-2022, 05:38 PM   #3
BoraxMan
Member
 
Registered: Apr 2010
Posts: 103

Original Poster
Rep: Reputation: 11
Quote:
Originally Posted by zeebra View Post
Well, obviously it COULD be that there is an actual physical issue with your "power key". What kind of key is it anyways, where is it placed and how does it look, how is it pressed etc?
It is a standard "soft power off" button on the front of the case. My case is a desktop tower, 12 years old. It could be the key, but if it were, my computer would randomly decide to shutdown, or fail to turn on. That is to say, it would send the signal at random.

Quote:
Another obvious possibility seems to be that your system interprets any keypress as the "power key" when in sleep mode. Could that be the case, and why would it do that?

Or it could be neither of those things, some sort of bug, and since the log says systemd is responsible, perhaps it could be a bug there, or perhaps it could help to look into its configuration somehow. Furthermore, if you want to look online for possible solutions, look into similar "systemd" issues. Perhaps also have a further dive into systemd logs (journald) and find all possible information, and look into as much as possible any systemd settings. UDEV is part of systemd, and I think responsible for the "power key" settings/definitions/implementations etc.

In the end, are there any other reasons the "power key" could be pressed? What exactly is the definition of "power key" on your system? Does it have several definitions? Or is it ONLY interpreted as the actual single on/off button? What kind of other "signals" could be interpreted as the "power key"?

If you can't figure it out, and you feel like going advanced to find the issue, do consider using Linux Audit to get the accurate details as to what is going on and trace the root cause.
These are the questions I guess I'm trying to answer, but not sure how. Linux today is a lot more complex than it was when I started using it 22 years ago, with so many more moving parts. I'm unsure how to go about troubleshooting it, or even finding which configuration files may be responsible.

What I'm really asking for here, is help on how to go about troubleshooting, or what potential culprits/configurations may be responsible, so I can target those first.

Thanks.
 
Old 11-12-2022, 10:20 PM   #4
mrapathy
Member
 
Registered: Nov 2005
Distribution: Slackware,Debian
Posts: 366

Rep: Reputation: 66
First off

What Desktop and Distro you using?

Have you tried checking your power management settings for your desktop?

Then check hotkey settings

Last edited by mrapathy; 11-12-2022 at 10:21 PM.
 
Old 11-13-2022, 03:59 AM   #5
zeebra
Senior Member
 
Registered: Dec 2011
Distribution: Slackware
Posts: 1,830
Blog Entries: 17

Rep: Reputation: 638Reputation: 638Reputation: 638Reputation: 638Reputation: 638Reputation: 638
Quote:
Originally Posted by BoraxMan View Post
What I'm really asking for here, is help on how to go about troubleshooting, or what potential culprits/configurations may be responsible, so I can target those first.
Well, the big hammer here is Linux Audit system. You can use it to trace down the issue exactly. "Who is sending the signal", "what signal is being sent", "and by who", it can answer those. "who" can be multiples and mean several things and most likely have to be backward traced.

And I'm saying that, because as you say, the issue seems very difficult to trace. It would take a fair bit of setup to get it right, but with it, you can find the issue for sure.

Last edited by zeebra; 11-13-2022 at 04:49 AM.
 
Old 11-14-2022, 05:40 AM   #6
BoraxMan
Member
 
Registered: Apr 2010
Posts: 103

Original Poster
Rep: Reputation: 11
Quote:
Originally Posted by mrapathy View Post
First off

What Desktop and Distro you using?

Have you tried checking your power management settings for your desktop?

Then check hotkey settings
I'm running Fedora 35, and using the FVWM Window Manager, no Desktop Environment so therefore no power management. The issue still occurs if I shut down X11 (ie, stopping the X Display Manager) and issue sudo systemctl suspend from the command line.
 
Old 11-14-2022, 01:00 PM   #7
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, Slarm64 & Android
Posts: 16,294

Rep: Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322
I had this sort of thing on a different system. It's got to do with the number of things doing power control - acpi, systemd, the window manager & who know what else. Disable power saving on the window manager (probably the easiest) and see if that sorts it.

Mine used to hibernate twice because one queued the action while the other was hibernating. Then when it came up, it went down again.
 
Old 11-14-2022, 04:14 PM   #8
computersavvy
Senior Member
 
Registered: Aug 2016
Posts: 3,345

Rep: Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484
I assume since you are suspending that you may be using a laptop, and since nvidia-suspend is mentioned in what you posted, that you have an nvidia GPU in use.

What is the output from
Code:
 systemctl status nvidia-{suspend,resume,hibernate,powerd}
I would suggest that you go over to ask.fedoraproject.org and ask there since you have 2 very relevant factors they deal with regularly. First is the fact that you are running fedora and second is the support of nvidia on fedora. Suspend and hibernation are tricky with nvidia since the GPU memory needs to be saved and reactivating the nvidia GPU after suspend also requires restoring the GPU memory properly which is what those services assist in managing.

A third factor is that you seem to be using fedora 35 which will go EOL very shortly after fedora 37 is released, and prompt upgrade to a newer release is always a good plan.
 
Old 11-15-2022, 02:01 AM   #9
BoraxMan
Member
 
Registered: Apr 2010
Posts: 103

Original Poster
Rep: Reputation: 11
Quote:
Originally Posted by computersavvy View Post
I assume since you are suspending that you may be using a laptop, and since nvidia-suspend is mentioned in what you posted, that you have an nvidia GPU in use.

What is the output from
Code:
 systemctl status nvidia-{suspend,resume,hibernate,powerd}
I would suggest that you go over to ask.fedoraproject.org and ask there since you have 2 very relevant factors they deal with regularly. First is the fact that you are running fedora and second is the support of nvidia on fedora. Suspend and hibernation are tricky with nvidia since the GPU memory needs to be saved and reactivating the nvidia GPU after suspend also requires restoring the GPU memory properly which is what those services assist in managing.

A third factor is that you seem to be using fedora 35 which will go EOL very shortly after fedora 37 is released, and prompt upgrade to a newer release is always a good plan.
Output is below. My computer is a desktop. I may try the update to Fedora 37 and see what happens there. Thank you for your suggestion.

○ nvidia-suspend.service - NVIDIA system suspend actions
Loaded: loaded (/usr/lib/systemd/system/nvidia-suspend.service; enabled; vendor preset: disabled)
Active: inactive (dead)

○ nvidia-resume.service - NVIDIA system resume actions
Loaded: loaded (/usr/lib/systemd/system/nvidia-resume.service; enabled; vendor preset: disabled)
Active: inactive (dead)

○ nvidia-hibernate.service - NVIDIA system hibernate actions
Loaded: loaded (/usr/lib/systemd/system/nvidia-hibernate.service; enabled; vendor preset: disabled)
Active: inactive (dead)

○ nvidia-powerd.service - nvidia-powerd service
Loaded: loaded (/usr/lib/systemd/system/nvidia-powerd.service; disabled; vendor preset: disabled)
Active: inactive (dead)
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Powers of two, powers of Linux: 2048 at the command line LXer Syndicated Linux News 0 12-09-2018 02:12 PM
resume: could not stat the resume device file Zaskar Debian 17 03-29-2012 10:10 PM
Linux system powers down when the reboot command is issued. john.wythe@activant.com Linux - Hardware 2 01-04-2011 07:25 PM
resume: cannot stat resume device file sixerjman Linux - Kernel 0 05-27-2007 03:09 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware

All times are GMT -5. The time now is 06:00 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration