21

Something is causing suspend crash occasionally. When it does crash, the system freezes with a black screen and stays on, not suspending. This makes me have to hold the power button until the system shuts down.

One setting difference I have from most people is, I don't use the option that lets you suspend when the laptop lid is closed. So opening and closing the laptop lid has no actions. I like to press suspend manually. Could this preference change be the cause?

How can I start looking for what's causing the crash, since the crash doesn't display errors?

Improve this question

2 Answers 2

Reset to default
26

I don't think the setting you mention is related.

Trouble-shooting

Error messages relating to suspending are typically found in /var/log/pm-suspend.log so have a look there.

Typical cause

These problems are usually due to some process(es) stopping the system from being suspended.

Do

dmesg -T|grep Freez -A4

and look for these entries:

--
[sun mar  3 15:19:48 2013] Freezing user space processes ... 
[sun mar  3 15:20:08 2013] Freezing of tasks failed after 20.01 seconds (3 tasks refusing to freeze, wq_busy=0):
[sun mar  3 15:20:08 2013] mount.nfs       D e8631aa0     0  5518   5517 0x00800004
[sun mar  3 15:20:08 2013]  e8631b10 00000086 f7bc0e00 e8631aa0 c1053cb4 c1809020 c192ee00 c192ee00
--

Check the time stamps to see which of the reported problems relate to your try to suspend. In this case, it is mount.nfs that is causing the problems.

Suggested workaround

Have a script run automatically before suspending and have the script kill the offending process:

The user can provide scripts in the /etc/pm/sleep.d/ directory. Those scripts will be run by the system at suspend and resume. The file name should start with an ordering number. 00-49 is used for user scripts. For details, see man pm-suspend.

The script could look like this:

#!/bin/sh
(killall -9 mount.nfs; exit 0)

...with correpsonding entries for other processes that caused problems, if any.

Parenthesis and exit 0 is a trick: if the process isn't found, killall will exit with en error exit code which will cancel the entire suspend. The parenthesis will make killall run in a sub-shell which will exit with exit code 0, regardless of the killall exit code.

If you're having problems, check /var/log/pm-suspend.log since it will also log problems relating to running the scripts in /etc/pm/sleep.d/.

Improve this answer
8
  • 1
    I also needed another line: (killall -9 mount.nfs; exit 0) because sometimes it doesn't work with SIGUP only.
    – Juanin
    Apr 20, 2014 at 5:06
  • 1
    I wonder what percentage of the time the problem is a live network mount (as shown here). That was my problem too -- but it was sshfs instead of nfs.
    – Brent Bradburn
    Nov 15, 2017 at 11:21
  • 1
    Thank you! This solution was exactly what I needed. In my case was mount.ntfs that was causing me grief
    – Weston Ganger
    Oct 17, 2019 at 3:05
  • 1
    @Ramesh-X My case was a process reading from a NFS mounted dir. NFS server was down. This was on 18.04, and kill -9 was needed.
    – Ole Tange
    May 20, 2020 at 8:08
  • 1
    @Ramesh-X Yes, nothing has changed with the log /var/log/pm-suspend.log or with the ability to provide scripts in /etc/pm/sleep.d/ so this should still work.
    – Carl
    Jun 18, 2021 at 13:35
8

No, disabling the "suspend on lid close" function cannot affect manual suspend.

You would start by looking at the output of dmesg and the contents of /var/log/kern.log and /var/log/syslog for clues.

We can try to help if you share these with us. See this question for how:

How can I easily share the output of a command or a text file with others?

Improve this answer
2
  • Having a look at the mentioned log files is a good start. Suspend-specific log messages typically go into /var/log/pm-suspend.log though. (More details in my answer below.)
    – Carl
    Jun 18, 2021 at 13:14
  • For anyone else searching, I found that pm-suspend.log was always empty but I found what I needed in the syslog on my system. I ran this command to get some details and found "codium" was causing my trouble... grep -A 35 'Freezing of tasks failed' /var/log/syslog
    – schworak
    Nov 14, 2022 at 14:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .