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.
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.
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.
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.
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
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.
Hey there, using latest Manjaro, I’m also experiencing similar issues, unable to suspend my brand new Lenovo Ideapad Ryzen 5 laptop (it’s a 2019 model, but even then, it’s not old or legacy hardware)
I haven’t tried any special boot parameters yet, because I’m dealing with other issues first.
There’s a possibility that this Suspend issue is a collateral byproduct of THIS OTHER ISSUE HERE (pictures) (I made a separate thread for it in the hopes of assistance)
Does your machine happens to be an AMD Ryzen as well? Is it desktop or laptop?
One thing that you could, if you still have your Windows install on the disk, or even using “Live USB” tools like Windows PE images or even Hiren’s Boot DVD (it has a “mini” version of XP and 7 in some versions that runs directly from RAM) By the way, Windows PE images are not illegal, they are provided by Microsoft itself.
And then you do this: boot into Windows, try changing power plans or create a new power plan focused on Performance, change back-and-forth between Balanced (Energy Saving) plan and Performance plan. Leave it at performance in the end. Then, at the end Reboot (do not shutdown) and go into Linux. See if the suspend issue persists then or if there are changes.
Maybe the system is unable to reach S3 states because of some limitations imposed by power plans? (this is preventing me from reaching higher advertised clocks on Linux)
Since you are there already, might as well test this hypothesis.
Then after that, do another test, but this time leave Windows in the Balanced (Energy Saving) plan before rebooting, to see if there are changes in behavior.
If we are able to track down the root for this problem, we will be able to fix both issues with a single shot, if they are related.
