Problem entering S3 state

I’ve been using Manjaro for a few months now, and everything is working well, except when I try to suspend to RAM (S3 sleep state). Sometimes it will work exactly as it should, but about half the time it will fail to sleep. Once it has failed to sleep, any future attempts to sleep will also not work, and various systems (such as networking) will be disabled or non-functional. My only option at that point is to reboot, and then try again and hope it will succeed.

I’ve noticed a few things when the system fails to sleep, but they may be unrelated to the problem. The first is that I see a message that it was unable to unmount some of my mounted SMB shares. This message, along with the unpredictability of the sleep failure, led me to be believe the problem was a race condition related to the networking shutting down before the SMB shares could unmount. However, I’ve manually unmounted the SMB shares before sleeping, and the problem can still occur, so I think this may be a dead end.

The other thing I’ve noticed is that once it’s failed to sleep, the system is actually still trying to sleep. For example, if I attempt a shutdown or reboot once it fails, the system will at some point actually go into the S3 state. However, once I power back up from this state, after some time passes (~60 to 90 seconds or so) the system will shutdown/restart (whichever I told it to do). It’s as if the sleep is “queued” but it doesn’t get there until whatever is preventing it from sleeping finally gets terminated during shut down. Once that is out of the way, it enters sleep even though it’s in the middle of shutdown, and then when powering back up it simply resumes shutting down.

Finally, some things always happen when I try to enter sleep, regardless of if it actually gets there or not. For example, my monitor will always blank when I attempt to enter sleep.

If you need to know my hardware, kernel, etc., those are in my profile. If you need anything else, or have a recommendation on how to begin troubleshooting the issue, please let me know.

When it fails and you then reboot, get the output of the following command:
journalctl -xe -p3 -b-1

1 Like

It was behaving for a while, but it finally happened again. The log of the time just before it failed to sleep is quite long, so I’ve put it on a pastebin here. I’m guessing only the last two lines are relevant to the issue?

Where is /mnt/zrs? Is it a remote filesystem? Also, you should always post the command which retrieved the output, so there are no doubts of what we’re talking about. The command I gave you above gets the last error messages from the previous boot. So it will post the journal until the system fails to log.

1 Like

Also provide the contents of the mnt-zrs.mount.service file, please? :innocent:

1 Like

Where is /mnt/zrs ? Is it a remote filesystem?

Yes, it’s a SMB/CIFS share. However, as I said in my original post, even if I unmount this prior to attempting to enter the sleep state, the problem can still occur, so I don’t think this is related.

Also, you should always post the command which retrieved the output, so there are no doubts of what we’re talking about. The command I gave you above gets the last error messages from the previous boot. So it will post the journal until the system fails to log.

It’s exactly the same command you posted. I only trimmed items that happened long before I attempted to enter sleep, and those that happened well after (i.e. when I eventually shut it down).

Also provide the contents of the mnt-zrs.mount.service file, please?

I’m not using a service file to mount it. I’ve just added an entry in /etc/fstab, and I manually mount it from a terminal when I need access to it.

Give the relevant line from fstab and the actual mount command (without password) then as

(emphasis mine)

also: don’t trim anything and if the output of is too big, use https://pastebin.com

Now:

  • note the exact time
  • execute systemctl suspend
  • execute systemctl --since "YYYY-MM-DD HH:MM:SS" where “YYYY-MM-DD HH:MM:SS”` is obviously todays’s date and the exact time you noted before.

:innocent:

1 Like

Exactly. The -xe flag already trims the log and outputs it in the ending. So I doubt the log is that big if you actually use the command I provided you.

1 Like

I restarted my computer with the express purpose of diagnosing this today, and this time I avoided mounting the network shares at all to prove that it’s totally unrelated to that. It took two attempts to cause the problem; the first time it entered sleep successfully (14:12), so I waited a bit to temporally separate any timestamps in the log. The second time I attempted it (14:22) it failed, and again with the message:

Sep 27 14:22:38 titanite systemd-cryptsetup[4903]: Device luks-0026ff7e-9827-45f2-835d-84b1d22607f3 is still in use.
Sep 27 14:22:38 titanite systemd-cryptsetup[4903]: Failed to deactivate: Device or resource busy

Anyway, the full log is available here.

Some motherboards do not like SSD upgrades. Is it a desktop? Do you have an SSD?

I have several, and yes this is a desktop. The OS is on one (SATA) SSD, and there’s another NVMe SSD (M.2) as well.

Also, they aren’t an “upgrade” in the sense that this is not an OEM/prebuilt PC. I ordered/assembled all the components for it.

There is no mention of suspend in your log at all.

Please:

  • Reboot

  • Execute:

     journalctl --system --boot=0 | grep "suspend entry"
     journalctl --system --boot=0 | grep "suspend exit"
    
  • and then do a:

    journalctl --since "YYYY-MM-DD HH:MM:SS" --until "YYYY-MM-DD HH:MM:SS"
    

    Where obviously the --since and --until are the suspension entry and exit.

:innocent:

I’ve already rebooted since then, so I assume you want the same boot as was posted in the earlier log (currently --boot=-1). Anyway, here are the two suspends, first the one that worked:

$ journalctl --since "2020-09-27 14:12:05" --until "2020-09-27 14:12:14"
-- Logs begin at Wed 2020-06-17 02:55:14 CDT, end at Mon 2020-09-28 03:01:01 CDT. --
Sep 27 14:12:05 titanite systemd-sleep[2875]: Suspending system...
Sep 27 14:12:05 titanite kernel: PM: suspend entry (deep)
Sep 27 14:12:05 titanite kernel: Filesystems sync: 0.020 seconds
Sep 27 14:12:05 titanite rtkit-daemon[2257]: Supervising 4 threads of 1 processes of 1 users.
Sep 27 14:12:05 titanite rtkit-daemon[2257]: Successfully made thread 3082 of process 2249 owned by '1000' RT at priority 5.
Sep 27 14:12:05 titanite rtkit-daemon[2257]: Supervising 5 threads of 1 processes of 1 users.

…and here’s the one that didn’t. The reason you see the whole system shutdown here is that, since it failed to enter sleep, I tried to shut it down. Then, part of the way through the shutdown process, it does go to sleep, as I mentioned in an earlier post.