[SOLVED] Mint 21.3 Cinnamon PC goes to sleep after several hours and does not wake

[RefreshMint]

Something really weird just happened in the last ~90 minutes. I walked away from my PC around 2 hours ago, and when I returned it had rebooted. Though, as usual, nothing in the logs indicate why that would have happened. And I did not reboot the machine manually (or remotely).

Uptime of other machines connected to the same circuit are 25 hours and 14 hours, so there wasn't a generalized loss of power. All three are connected to a UPS as well.

https://termbin.com/lvt9

I'll revert back to a 6.2 kernel to see if stability returns. This is just so strange.

[SMG]

Something really weird just happened in the last ~90 minutes. I walked away from my PC around 2 hours ago, and when I returned it had rebooted. Though, as usual, nothing in the logs indicate why that would have happened. And I did not reboot the machine manually (or remotely).

That can sometimes be a sign of a PSU issue.

Log looks like the others.

[RefreshMint]

6.2 just experienced another "power event" type reboot. Came back after ~5-ish hours, woke the screens up to a login screen (not screensaver) and an uptime of 3.5 hours. Looks like some errors in the cinnamon Screensaver again a few minutes before the unattended reboot.

Code: Select all

Feb 29 13:31:34 Dodecacore org.cinnamon.ScreenSaver[18715]: Fractional scaling active: False
Feb 29 13:31:34 Dodecacore org.cinnamon.ScreenSaver[18715]: Fractional scaling active: False
Feb 29 13:31:34 Dodecacore org.cinnamon.ScreenSaver[18715]: Fractional scaling active: False
Feb 29 13:31:38 Dodecacore cinnamon-screensaver-pam-helper[19138]: pam_ecryptfs: seteuid error
Feb 29 13:31:38 Dodecacore cinnamon-screensaver-pam-helper[19138]: gkr-pam: unlocked login keyring
Feb 29 13:32:08 Dodecacore cinnamon-session[2036]: WARNING: t+49240.37571s: Detected that screensaver has left the bus
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Error in sys.excepthook:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Original exception was:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Error in sys.excepthook:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Original exception was:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Error in sys.excepthook:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Original exception was:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Error in sys.excepthook:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Original exception was:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Error in sys.excepthook:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Original exception was:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Error in sys.excepthook:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Original exception was:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Error in sys.excepthook:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Original exception was:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Error in sys.excepthook:
Feb 29 13:32:08 Dodecacore org.cinnamon.ScreenSaver[18715]: Original exception was:
Feb 29 13:32:38 Dodecacore systemd[1]: Started Run anacron jobs.
Feb 29 13:32:38 Dodecacore anacron[19187]: Anacron 2.3 started on 2024-02-29
Feb 29 13:32:38 Dodecacore anacron[19187]: Normal exit (0 jobs run)
Feb 29 13:32:38 Dodecacore systemd[1]: anacron.service: Deactivated successfully.
Feb 29 13:36:45 Dodecacore dbus-daemon[2035]: [session uid=1000 pid=2035] Activating service name='org.cinnamon.ScreenSaver' requested by ':1.219' (uid=1000 pid=19204 comm="/usr/bin/python3 /usr/share/cinnamon-screensaver/c" label="unconfined")
Feb 29 13:36:45 Dodecacore org.cinnamon.ScreenSaver[19210]: Loading AccountsService
Feb 29 13:36:45 Dodecacore org.cinnamon.ScreenSaver[19210]: Fractional scaling active: False
Feb 29 13:36:45 Dodecacore org.cinnamon.ScreenSaver[19210]: Trying to connect to logind...
Feb 29 13:36:45 Dodecacore dbus-daemon[2035]: [session uid=1000 pid=2035] Successfully activated service 'org.cinnamon.ScreenSaver'
Feb 29 13:36:45 Dodecacore org.cinnamon.ScreenSaver[19210]: Starting screensaver...
Feb 29 13:36:45 Dodecacore org.cinnamon.ScreenSaver[19210]: Cinnamon Screensaver support not found in current theme - adding some...
Feb 29 13:36:45 Dodecacore cinnamon-session[2036]: WARNING: t+49517.38646s: Detected that screensaver has appeared on the bus
Feb 29 13:36:45 Dodecacore org.cinnamon.ScreenSaver[19210]: AccountsService ready
Feb 29 13:36:45 Dodecacore org.cinnamon.ScreenSaver[19210]: Successfully using logind
Feb 29 13:46:55 Dodecacore rtkit-daemon[1865]: Supervising 9 threads of 7 processes of 1 users.
Feb 29 13:46:55 Dodecacore rtkit-daemon[1865]: Successfully made thread 19276 of process 2029 owned by '1000' RT at priority 5.
Feb 29 13:46:55 Dodecacore rtkit-daemon[1865]: Supervising 10 threads of 7 processes of 1 users.

from the logs uploaded here https://termbin.com/mkzl

Doesn't seem to be a 6.5 kernel issue, unless it's a holdover from 6.2 that made it into 6.5. And it's looking more like a screensaver problem, as the only common denominator between them all is that they've all occurred at times when the screensaver should be displaying (or the screens should be asleep).

My next step will be to disable the screensaver and leave the screen power off timer in the power settings to see if that makes a difference (and verify the power cable is firmly seated in the PSU's socket).

[RefreshMint]

Well that didn't take long. Went to use the PC again after making dinner and it was locked up at the desktop with no screensaver. Journal indicated it had only been up for 2 minutes.

https://termbin.com/0c0c

However, boot before that was up for longer:

https://termbin.com/dvh9

Still weird to have two separate 'boot' events since I last used the machine, especially when the -2 ended just after I last used it and the -1 started over an hour after the previous. Unless the machine was didn't actually sync time until I logged in? Seems quite odd.

Never had these types off issues when using Win10 or Ubuntu 22 before switching to Mint, which makes me believe it's OS specific. And I really don't want to go back to either of those =)

I did just notice I had the 'Lock the computer after screensaver starts' still enabled while 'delay before starting the screensaver' was 'Never'. So I'm also disabling that from locking in case that was confusing things too.

[SMG]

6.2 just experienced another "power event" type reboot. Came back after ~5-ish hours, woke the screens up to a login screen (not screensaver) and an uptime of 3.5 hours. Looks like some errors in the cinnamon Screensaver again a few minutes before the unattended reboot.

If the Cinnamon desktop and or the X Server crash, it will take you back to the login screen. That is not a reboot. However, the log information you are posting is not showing a crash.

Is there anything in the System Reports app on the Crash reports tab?

[SMG]

Well that didn't take long. Went to use the PC again after making dinner and it was locked up at the desktop with no screensaver. Journal indicated it had only been up for 2 minutes.

https://termbin.com/0c0c

However, boot before that was up for longer:

https://termbin.com/dvh9

Still weird to have two separate 'boot' events since I last used the machine, especially when the -2 ended just after I last used it and the -1 started over an hour after the previous. Unless the machine was didn't actually sync time until I logged in? Seems quite odd.

This sounds like a hardware related issue. There is no "reboot" line in the logs you have been posting which means the entire PC (or the drive on the PC) is losing power and then getting it back and automatically restarting.

[RefreshMint]

I didn't see a reboot command in the logs either, which I why I put "reboot" in quotes =) It acted like the same thing. I didn't realize that if Cinnamon/desktop crashed it would return me to the login GUI. So definitely more in line with a crash than a reboot!

There are a few crash reports, two for /usr/bin/cinnamon and two for /usr/bin/python3.10

The cinnamon ones can't be resolved, probably due to kernel or video driver changes

The headers or binaries installed on your system do not match the code which was executed during the crash.
They probably got upgraded since.
A stack trace is available in 'Local Files' but its content is probably inaccurate.

One of the python crashes resolved quickly: https://termbin.com/pfah
The second python crash took several minutes to resolve: https://termbin.com/6huc

The both point to the cinnamon-settin process as the culprit. Which tracks with the other two /usr/bin/cinnamon reports.

The bug report link redirects to a launchpad error landing page https://bugs.launchpad.net/python3.10-minimal so I'm not entirely sure how to report it or where to share the crash details. =(

There are only 4 crash reports listed, and all are from the past 2 days. Do they expire after a certain period of time or did the other events not generate crash reports?

[SMG]

There are only 4 crash reports listed, and all are from the past 2 days. Do they expire after a certain period of time or did the other events not generate crash reports?

The logs are cleared on a weekly basis.

I didn't see a reboot command in the logs either, which I why I put "reboot" in quotes =) It acted like the same thing. I didn't realize that if Cinnamon/desktop crashed it would return me to the login GUI. So definitely more in line with a crash than a reboot!

A crash should show in the .xsession-errors or .xsession-errors.old files (hidden files in your /home) as well as in Crash reports. The xsession files would give the information leading up to the crash.

There are a few crash reports, two for /usr/bin/cinnamon and two for /usr/bin/python3.10

No, that is not what you posted.

The cinnamon ones can't be resolved, probably due to kernel or video driver changes

The headers or binaries installed on your system do not match the code which was executed during the crash.
They probably got upgraded since.
A stack trace is available in 'Local Files' but its content is probably inaccurate.

From where did you get that quoted message? I've never heard of it.

One of the python crashes resolved quickly: https://termbin.com/pfah

I have no idea what you mean by it "resolved quickly". That shows a SegFault with a core dump. And it is not a python crash. It appears to indicate you created something of your own. You created a process called cinnamon-settin (no g at the end of setting) which consists of the command line listed below.

Code: Select all

           PID: 3928 (cinnamon-settin)
           UID: 1000 (jebus)
           GID: 1000 (jebus)
        Signal: 11 (SEGV)
     Timestamp: Wed 2024-02-28 23:25:56 CST (1 day 12h ago)
  Command Line: cinnamon-settings "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""

The second python crash took several minutes to resolve: https://termbin.com/6huc

No, it did not resolve. It's the same message as the prior one. It's a seg fault with what appears to be a custom command line.

The both point to the cinnamon-settin process as the culprit. Which tracks with the other two /usr/bin/cinnamon reports.

What are the top 20 lines of the other two reports?

[RefreshMint]

From where did you get that quoted message?

That's displayed in the 'Stack trace' area of the Crash Report section in System Reports. That text displays for both the /usr/bin/cinnamon reports.

SystemReportCrashReportStackTrace

I have no idea what you mean by it "resolved quickly".

Poor terminology on my part, sorry! By "resolved quickly" I meant the spinner that appears after selecting a crash report disappeared and its details populated in the window. I wasn't sure the official verbiage for that so I made something up that caused confusion. =) And also wanted to be clear that one of them took several minutes longer to populate, in case that was indicative of anything.

I'm archiving all four of those current crash reports to save them from being cleared, just to be safe.

You created a process called cinnamon-settin

Someone created that process, for certain, but I have no idea who. There isn't a cinnamon-settin file located on my machine anywhere. Possibly a bug in the System Reporter collection? Or the crash dump corrupted the last few characters of the process name?

Code: Select all

jebus@Dodecacore:~$ sudo find / -type f -name "cinnamon-settin"
find: ‘/proc/2269/task/2269/net’: Invalid argument
find: ‘/proc/2269/net’: Invalid argument
find: ‘/proc/4144/task/4144/net’: Invalid argument
find: ‘/proc/4144/net’: Invalid argument
find: ‘/run/user/1000/doc’: Permission denied
find: ‘/run/user/1000/gvfs’: Permission denied
jebus@Dodecacore:~$ 

Diving into the .xsession-errors https://termbin.com/t4es and .xsession-errors.old https://termbin.com/ktpv they both show CRITICAL messages indicating something to do with Gtk Widgets. The current when destroying a widget:

(nemo:2941): Gtk-CRITICAL **: 14:23:42.103: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed
Nemo-Share-Message: 14:27:11.149: Called "net usershare info" but it failed: 'net usershare' returned error 255: net usershare: cannot open usershare directory /var/lib/samba/usershares. Error No such file or directory
Please ask your system administrator to enable user sharing.

and the .old shows cinnamon.desktop being killed:

(cinnamon-session-quit.py:28997): GLib-GObject-WARNING **: 09:08:55.148: invalid unclassed pointer in cast to 'GtkWidget'

(cinnamon-session-quit.py:28997): GLib-GObject-WARNING **: 09:08:55.148: instance with invalid (NULL) class pointer

(cinnamon-session-quit.py:28997): GLib-GObject-CRITICAL **: 09:08:55.148: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
cinnamon-session[1436]: WARNING: t+664.75779s: Finished playing logout sound
cinnamon-session[1436]: WARNING: t+664.75784s: Resuming logout sequence...
cinnamon-session[1436]: WARNING: t+665.64090s: Requesting system restart...
cinnamon-session[1436]: WARNING: t+665.64094s: Attempting to restart using systemd...

(csd-print-notifications:1727): GLib-CRITICAL **: 09:08:57.180: Source ID 3 was not found when attempting to remove it
Gjs-Message: 09:08:57.181: JS LOG: [LookingGlass/error] GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.cinnamon.SettingsDaemon.Power was not provided by any .service files
Gjs-Message: 09:08:57.181: JS LOG: [LookingGlass/trace]
<----------------
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:114:23
---------------->
cinnamon-session[1436]: WARNING: t+665.67491s: Application 'cinnamon.desktop' killed by signal 15

(cinnamon:29162): mutter-WARNING **: 09:08:57.847: Failed to create backend: Unable to open display ':0'

Not sure what killed it though. I've also switched to the latest oem kernel in hopes of better stability.

Are you able to make more sense of the errors?

And, as always, thank you for all the help!

[SMG]

I've also switched to the latest oem kernel in hopes of better stability.

That is probably why you are getting the error message about "The headers or binaries installed on your system do not match the code which was executed during the crash."

I have no idea what you mean by it "resolved quickly".

Poor terminology on my part, sorry! By "resolved quickly" I meant the spinner that appears after selecting a crash report disappeared and its details populated in the window. I wasn't sure the official verbiage for that so I made something up that caused confusion. =) And also wanted to be clear that one of them took several minutes longer to populate, in case that was indicative of anything.

I am not aware that it is indicative of anything other than how long the app takes to process your request.

There isn't a cinnamon-settin file located on my machine anywhere.

The message indicated it is a cinnamon-settin process which is called from the command line with

Code: Select all

cinnamon-settings "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""

No one said anything about there being a cinnamon-settin file on your computer.

Diving into the .xsession-errors https://termbin.com/t4es and .xsession-errors.old https://termbin.com/ktpv they both show CRITICAL messages indicating something to do with Gtk Widgets. The current when destroying a widget:

Code: Select all

(nemo:2941): Gtk-CRITICAL **: 14:23:42.103: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed
Nemo-Share-Message: 14:27:11.149: Called "net usershare info" but it failed: 'net usershare' returned error 255: net usershare: cannot open usershare directory /var/lib/samba/usershares. Error No such file or directory
Please ask your system administrator to enable user sharing.
[/quote][/quote]Most people do not have samba enabled and see that message. 

[quote=RefreshMint post_id=2439089 time=1709327966 user_id=364538]
and the .old shows cinnamon.desktop being killed:
[quote]
 (cinnamon-session-quit.py:28997): GLib-GObject-WARNING **: 09:08:55.148: invalid unclassed pointer in cast to 'GtkWidget'

(cinnamon-session-quit.py:28997): GLib-GObject-WARNING **: 09:08:55.148: instance with invalid (NULL) class pointer

(cinnamon-session-quit.py:28997): GLib-GObject-CRITICAL **: 09:08:55.148: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
cinnamon-session[1436]: WARNING: t+664.75779s: Finished playing logout sound
cinnamon-session[1436]: WARNING: t+664.75784s: Resuming logout sequence...
cinnamon-session[1436]: WARNING: t+665.64090s: Requesting system restart...
cinnamon-session[1436]: WARNING: t+665.64094s: Attempting to restart using systemd...

(csd-print-notifications:1727): GLib-CRITICAL **: 09:08:57.180: Source ID 3 was not found when attempting to remove it
Gjs-Message: 09:08:57.181: JS LOG: [LookingGlass/error] GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.cinnamon.SettingsDaemon.Power was not provided by any .service files
Gjs-Message: 09:08:57.181: JS LOG: [LookingGlass/trace] 
<----------------
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:114:23
---------------->
cinnamon-session[1436]: WARNING: t+665.67491s: Application 'cinnamon.desktop' killed by signal 15

(cinnamon:29162): mutter-WARNING **: 09:08:57.847: Failed to create backend: Unable to open display ':0'

Not sure what killed it though.

You left out the lines right before that started which indicated you must have installed and then possibly removed openrgb.desktop.

Code: Select all

cinnamon-session[1436]: WARNING: t+663.60076s: Unable to find desktop file 'openrgb.desktop'
cinnamon-session[1436]: WARNING: t+663.60106s: Unable to find desktop file 'gnome-openrgb.desktop'

Did you take a Timeshift snapshot before installing from the below PPA?

Code: Select all

  Active apt repos in: /etc/apt/sources.list.d/thopiekar-openrgb-jammy.list
    1: deb [signed-by=/etc/apt/keyrings/thopiekar-openrgb-jammy.gpg] https://ppa.launchpadcontent.net/thopiekar/openrgb/ubuntu jammy main

In the current .xsession-errors file is the below which seems to be for Intel graphics which you do not have.

Code: Select all

libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)

It it starting to appear there may be something you installed which is causing the instability issues.

Please create a new user and log in as the new user and see if the problems continue.

[RefreshMint]

Did you take a Timeshift snapshot before installing from the below PPA?

Unfortunately, I did not. I pretty much set up my machine they way I wanted and started using it... then started seeing the instability issues =(

You left out the lines right before that started which indicated you must have installed and then possibly removed openrgb.desktop.

It it starting to appear there may be something you installed which is causing the instability issues.

I wonder if maybe having openrgb running may be causing the problems? I didn't remove the app/shortcut, though I do have a desktop icon for it, which could be where the openrgb.desktop reference is coming from (OpenRGB.desktop does exist in my user's Desktop directory - though there is no gnome-openrgb.desktop file). I'll rename that to be lowercase too, just in case.

Or maybe the instability could be stemming from the fact I installed openrgb via the additional repo instead of the flatpak?

I'm going to uninstall openrgb, remove that source repo, and try the flatpak instead. I don't remember if there was a reason I didn't use the flatpak in the first place, other than a preference for .deb packages.

Fingers crossed that openrgb is the culprit! It'd be a relief to have an answer =)

[SMG]

I wonder if maybe having openrgb running may be causing the problems?

I am not familiar with the app to have any idea if it would or would not be a factor. Sometimes apps pull in other dependencies which can cause issues.

Based on the messages, it would seem to be something you installed on your desktop which is causing the issue.

Or maybe the instability could be stemming from the fact I installed openrgb via the additional repo instead of the flatpak?

I have no clue.

[RefreshMint]

I'm sitting at 62 hours uptime with the 6.5.0-1015-oem kernel and the flatpak install of OpenRGB (instead of the external repository version) with no issues. Going to switch back to the 6.5.0-21 kernel to rule out oem vs. ubuntu kernel as a contributing factor.

Looks like we're narrowing in on the cause!

Thank you for all the help interpreting the data/crashes/logs, never would have gotten this far without the assistance!

[SMG]

I'm sitting at 62 hours uptime with the 6.5.0-1015-oem kernel and the flatpak install of OpenRGB (instead of the external repository version) with no issues. Going to switch back to the 6.5.0-21 kernel to rule out oem vs. ubuntu kernel as a contributing factor.

[RefreshMint]

I am just about at 60 hours uptime since reverting back to the 6.5.0-21 kernel from the oem, after reinstalling OpenRGB as a flatpak and have not experienced the issue since. My money's on having installed OpenRGB from an external repo as the reason for the instability.

Thank you again for all the help in diagnosing the problem! I never would have tracked this down without your help. And, added bonus, I learned a lot about Mint along the way.

I'll mark this as solved - thank you!

[RefreshMint]

Back again with an update. The OpenRGB from the non-stock repo was not the ultimate culprit. I was still having the system freeze after a few hours of being idle. It appeared as though that had fixed the issue because the time it was up it wasn't idle, it was performing a data migration that took almost two days.

After spending the last several weeks troubleshooting the system freeze, and discovering it happeened even on a fresh install of both Mint Cinnamon and LMDE, the solution has been found. Disabling CPU C-States in the BIOS. With Global CPU C-States disabled the machine has been up for > 60 hours with several 3+ hour and 8+ hour idle sessions. I'm confident now that it is solved.

Will edit and update the first post as well for anyone else who might be experiencing this issue. I'm guessing even with the latest amd64-microcode package there may still be some edge cases with Ryzen C-States.