Is like if i just boot my pc, closing all stuffs that was opened
Im on fedora SB 40, but this issue is old, have on past fedoras
It might have to do with your power settings. What is the output of gsettings list-recursively org.gnome.settings-daemon.plugins.power ?
thanks for your reply
org.gnome.settings-daemon.plugins.power ambient-enabled true
org.gnome.settings-daemon.plugins.power idle-brightness 30
org.gnome.settings-daemon.plugins.power idle-dim true
org.gnome.settings-daemon.plugins.power power-button-action 'interactive'
org.gnome.settings-daemon.plugins.power power-saver-profile-on-low-battery false
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 3600
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 3600
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'suspend'
I use a laptop that is always plugged, so it never get low battery
I’ve never seen this on Workstation for years and all of F40, but also never used Silverblue.
My first guess is OOM killer being engaged to kill the GNOME session (and if it’s Wayland then everything else with it); there’s some logs you can check if OOM happens.
1 Like
I am also wondering how long after inactivity does this happen. Could it be around the 3600 seconds value (i.e. one hour, as set up in the sleep-inactive-ac-timeout key)?
As @Espionage724 mentioned, there should be details in the logs. You could check with journalctl -b after the issue happens (and narrow down the output with -S and -U options if you would like to post it here).
There was this reported issue, might not apply to you, and besides, it got fixed.
i did a grep in jounalctl and dont found OOM killer, maybe should look in other place ?
ago 25 17:14:30 fedora kernel: Linux version 6.10.6-200.fc40.x86_64 (mockbuild@f1069ead281040288cd8d3761ad1265a) (gcc (>
ago 25 17:14:30 fedora kernel: Command line: BOOT_IMAGE=(hd1,gpt2)/ostree/fedora-59be2d3c2e314d8c78c4bbd16b7ce169820e66>
ago 25 17:14:30 fedora kernel: BIOS-provided physical RAM map:
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009efff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] usable
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x0000000000100000-0x000000003fffffff] usable
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x0000000040000000-0x00000000403fffff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x0000000040400000-0x000000006f06cfff] usable
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x000000006f06d000-0x000000006f06dfff] ACPI NVS
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x000000006f06e000-0x000000006f06efff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x000000006f06f000-0x000000007800ffff] usable
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x0000000078010000-0x000000007861bfff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x000000007861c000-0x0000000078698fff] ACPI data
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x0000000078699000-0x000000007879ffff] ACPI NVS
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x00000000787a0000-0x00000000791fdfff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x00000000791fe000-0x00000000791fefff] usable
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x00000000791ff000-0x000000007f7fffff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
ago 25 17:14:30 fedora kernel: BIOS-e820: [mem 0x0000000100000000-0x000000047e7fffff] usable
ago 25 17:14:30 fedora kernel: NX (Execute Disable) protection: active
ago 25 17:14:30 fedora kernel: APIC: Static calls initialized
ago 25 17:14:30 fedora kernel: e820: update [mem 0x6390a018-0x63918857] usable ==> usable
ago 25 17:14:30 fedora kernel: e820: update [mem 0x638f9018-0x63909057] usable ==> usable
ago 25 17:14:30 fedora kernel: extended physical RAM map:
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x0000000000000000-0x000000000009dfff] usable
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x000000000009e000-0x000000000009efff] reserved
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x000000000009f000-0x000000000009ffff] usable
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x00000000000a0000-0x00000000000fffff] reserved
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x0000000000100000-0x000000003fffffff] usable
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x0000000040000000-0x00000000403fffff] reserved
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x0000000040400000-0x00000000638f9017] usable
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x00000000638f9018-0x0000000063909057] usable
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x0000000063909058-0x000000006390a017] usable
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x000000006390a018-0x0000000063918857] usable
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x0000000063918858-0x000000006f06cfff] usable
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x000000006f06d000-0x000000006f06dfff] ACPI NVS
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x000000006f06e000-0x000000006f06efff] reserved
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x000000006f06f000-0x000000007800ffff] usable
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x0000000078010000-0x000000007861bfff] reserved
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x000000007861c000-0x0000000078698fff] ACPI data
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x0000000078699000-0x000000007879ffff] ACPI NVS
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x00000000787a0000-0x00000000791fdfff] reserved
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x00000000791fe000-0x00000000791fefff] usable
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x00000000791ff000-0x000000007f7fffff] reserved
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x00000000e0000000-0x00000000efffffff] reserved
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
ago 25 17:14:30 fedora kernel: reserve setup_data: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
issue happened again, almost everyday happens when i put pc in screen lock mode during the night. When i enter on the morning, is like it just boot
i dont think so, is very variable the issue, sometimes took longer then 1hour to happen
i think maybe nvidia could be the issue, although i use nouveau or thermal (in windows my notebook fan was always spinning making some noise, now with fedora, i never heard, so i think maybe my notebook is reaching certain temp and shutdown)
in the past i had problem with firefox flatpak, idk why, this issue happened multiple times during the day, and when my pc booted my second monitor was not recognized, so i would had to shutdown and boot again, when i uninstall firefox flatpak the problem was solved by the day (also solved the second monitor issue), but as i said i still have this problem usually during night. What is strange is that either case the problem happens always when pc in sleep mode.
i think the firefox problem that i had was because of the extensions , dark reader and ublock.
So, resuming, you guys could help me saying which commands i can use to track down if the issue is nvdia or thermal ?
You have only copied the output of journalctl that was presented on the terminal screen (first page, not the entire output).
To present the relevant part, you can run journalctl -S "YYYY-MM-DD HH:MM:SS" -U "YYYY-MM-DD HH:MM:SS" | fpaste --raw-url, by replacing the interval with the moment the system was left idle until it was waken up, and post here the generated link.
Sure
https://paste.centos.org/view/raw/fca5a051
idk the exactly time, but i think maybe was near the final part of the logs
Excerpt from the log:
set 01 01:54:32 fedora systemd[1]: Starting systemd-suspend.service - System Suspend...
set 01 01:54:32 fedora wpa_supplicant[1436]: wlp4s0: CTRL-EVENT-DSCP-POLICY clear_all
set 01 01:54:32 fedora systemd-sleep[644947]: Performing sleep operation 'suspend'...
set 01 01:54:32 fedora kernel: PM: suspend entry (s2idle)
set 01 01:54:32 fedora wpa_supplicant[1436]: wlp4s0: CTRL-EVENT-DSCP-POLICY clear_all
set 01 01:54:32 fedora wpa_supplicant[1436]: nl80211: deinit ifname=wlp4s0 disabled_11b_rates=0
set 01 01:54:32 fedora kernel: Filesystems sync: 0.026 seconds
The system is starting the suspend service at 01:54:32, however, these are also the last lines of the provided log output. The journalctl log should be extended (with the -U option) to the time you were trying to wake it up from sleep (in the morning I assume).
when you say suspend, you meant shutdown/restart ?
i was not using the computer at this time, it restart alone
https://paste.centos.org/view/raw/22328b31
i Extend more, to get the time i start using
There is a misunderstanding (at least on my part). I understood from the title that the issue was that the logged-in user got logged out, not that the system was shut down. Can you please clarify?
I have noticed the following in the logs, do tell if it makes sense and if it can be connected to user actions.
- At 01:39:14,
gnome-shellsegfaults and dumps core:
set 01 01:39:14 fedora gnome-shell[455150]: Failed to blit shared framebuffer: EGL failed to allocate resources for the requested operation.
set 01 01:39:14 fedora audit[455150]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=9 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=455150 comm="gnome-shell" exe="/usr/bin/gnome-shell" sig=11 res=1
set 01 01:39:14 fedora kernel: gnome-shell[455150]: segfault at ffffffffffffffec ip 00007f5317d9c532 sp 00007fff819084b0 error 5 in libmutter-14.so.0.0.0[19c532,7f5317c3f000+17e000] likely on CPU 7 (core 3, socket 0)
set 01 01:39:14 fedora kernel: Code: eb ea ff 48 8b 85 50 fe ff ff 48 89 43 50 4d 85 ed 0f 84 31 15 00 00 4c 89 ef e8 a9 74 eb ff 4c 8b 6b 50 48 63 05 16 78 0c 00 <41> 8b 44 05 0c 85 c0 75 1c 49 8b 45 00 48 8d b5 70 fe ff ff 4c 89
set 01 01:39:14 fedora audit: BPF prog-id=311 op=LOAD
set 01 01:39:14 fedora audit: BPF prog-id=312 op=LOAD
set 01 01:39:14 fedora audit: BPF prog-id=313 op=LOAD
set 01 01:39:14 fedora systemd[1]: Started systemd-coredump@3-643973-0.service - Process Core Dump (PID 643973/UID 0).
set 01 01:39:14 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@3-643973-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
set 01 01:39:15 fedora systemd-coredump[643974]: Process 455150 (gnome-shell) of user 1000 dumped core.
- At 01:54:32,
systemd-logindstarts suspending the system:
set 01 01:54:32 fedora kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
set 01 01:54:32 fedora kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
set 01 01:54:32 fedora systemd-logind[1262]: The system will suspend now!
[...]
set 01 01:54:32 fedora gnome-shell[644212]: Screen lock is locked down, not locking
[...]
set 01 01:54:32 fedora systemd-sleep[644947]: Performing sleep operation 'suspend'...
set 01 01:54:32 fedora kernel: PM: suspend entry (s2idle)
- No system logs until 12:10:14, when the system wakes up from suspend:
set 01 12:10:14 fedora systemd-sleep[644947]: System returned from sleep operation 'suspend'.
set 01 12:10:14 fedora kernel: PM: suspend exit
set 01 12:10:14 fedora systemd[1]: systemd-suspend.service: Deactivated successfully.
set 01 12:10:14 fedora 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'
set 01 12:10:14 fedora 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'
set 01 12:10:14 fedora systemd[1]: Finished systemd-suspend.service - System Suspend.
set 01 12:10:14 fedora systemd[1]: Stopped target sleep.target - Sleep.
set 01 12:10:14 fedora systemd[1]: Reached target suspend.target - Suspend.
set 01 12:10:14 fedora systemd[1]: Stopped target suspend.target - Suspend.
set 01 12:10:14 fedora systemd-logind[1262]: Operation 'suspend' finished.
So it is not that the user gets logged out as a result of, or after the suspend process, but rather before that, probably because of the segfault. The stack trace might yield something to you (or to others joining the conversation)?
Are there any GNOME Shell extensions that you are using? If yes, you might want to replicate with extensions disabled.
Please also send the output of inxi -Fzxx.
sorry, you are absolutely right, didnt came my attention that could be a logout , i though was a restart, because the behavior is the same when i wake up the computer
Extensions that i use:
- GSConnect
- Taskwidget
- Vitals
System:
Kernel: 6.10.6-200.fc40.x86_64 arch: x86_64 bits: 64 compiler: gcc
v: 2.41-37.fc40
Desktop: GNOME v: 46.4 tk: GTK v: 3.24.43 wm: gnome-shell dm: GDM
Distro: Fedora Linux 40.20240824.0 (Silverblue)
Machine:
Type: Laptop System: Dell product: G3 3590 v: N/A
serial: <superuser required> Chassis: type: 10 serial: <superuser required>
Mobo: Dell model: 0GDFK2 v: A00 serial: <superuser required> part-nu: 0949
UEFI: Dell v: 1.21.0 date: 04/10/2023
Battery:
ID-1: BAT0 charge: 34.3 Wh (100.0%) condition: 34.3/51.0 Wh (67.2%)
volts: 12.3 min: 11.4 model: LGC-LGC4.474 DELL 415CG01 serial: <filter>
status: full
CPU:
Info: quad core model: Intel Core i5-9300H bits: 64 type: MT MCP
arch: Coffee Lake rev: A cache: L1: 256 KiB L2: 1024 KiB L3: 8 MiB
Speed (MHz): avg: 1212 high: 4100 min/max: 800/4100 cores: 1: 800 2: 800
3: 4100 4: 800 5: 800 6: 800 7: 800 8: 800 bogomips: 38400
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: Intel CoffeeLake-H GT2 [UHD Graphics 630] vendor: Dell
driver: i915 v: kernel arch: Gen-9.5 ports: active: DP-3 off: eDP-1
empty: DP-1,DP-4,HDMI-A-1 bus-ID: 00:02.0 chip-ID: 8086:3e9b
Device-2: NVIDIA TU117M [GeForce GTX 1650 Mobile / Max-Q] vendor: Dell
driver: nouveau v: kernel arch: Turing pcie: speed: 2.5 GT/s lanes: 8 ports:
active: HDMI-A-2 empty: none bus-ID: 01:00.0 chip-ID: 10de:1f91
Device-3: Microdia Integrated_Webcam_HD driver: uvcvideo type: USB
rev: 2.0 speed: 480 Mb/s lanes: 1 bus-ID: 1-5:6 chip-ID: 0c45:671f
Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 24.1.2
compositor: gnome-shell driver: gpu: i915,nouveau display-ID: 0
Monitor-1: DP-3 model: LG (GoldStar) ULTRAWIDE res: 2560x1080 dpi: 81
diag: 869mm (34.2")
Monitor-2: HDMI-A-2 model: AOC 27B1G5 res: 1920x1080 dpi: 82
diag: 686mm (27")
Monitor-3: eDP-1 model: BOE Display 0x0819 res: 1920x1080 dpi: 142
diag: 395mm (15.5")
API: OpenGL v: 4.6 vendor: intel mesa v: 24.1.6 glx-v: 1.4 es-v: 3.2
direct-render: yes renderer: Mesa Intel UHD Graphics 630 (CFL GT2)
device-ID: 8086:3e9b display-ID: :0.0
API: EGL Message: EGL data requires eglinfo. Check --recommends.
Audio:
Device-1: Intel Cannon Lake PCH cAVS vendor: Dell
driver: sof-audio-pci-intel-cnl bus-ID: 00:1f.3 chip-ID: 8086:a348
Device-2: NVIDIA vendor: Dell driver: snd_hda_intel v: kernel pcie:
speed: 2.5 GT/s lanes: 8 bus-ID: 01:00.1 chip-ID: 10de:10fa
API: ALSA v: k6.10.6-200.fc40.x86_64 status: kernel-api
Server-1: PipeWire v: 1.0.7 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin
Network:
Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
vendor: Dell driver: r8169 v: kernel pcie: speed: 2.5 GT/s lanes: 1
port: 3000 bus-ID: 03:00.0 chip-ID: 10ec:8168
IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Device-2: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter
vendor: Dell driver: ath10k_pci v: kernel pcie: speed: 2.5 GT/s lanes: 1
bus-ID: 04:00.0 chip-ID: 168c:0042
IF: wlp4s0 state: up mac: <filter>
Bluetooth:
Device-1: Qualcomm Atheros driver: btusb v: 0.8 type: USB rev: 2.0
speed: 12 Mb/s lanes: 1 bus-ID: 1-14:8 chip-ID: 0cf3:e009
Report: btmgmt ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 4.2
lmp-v: 8
Drives:
Local Storage: total: 1.83 TiB used: 631.06 GiB (33.7%)
ID-1: /dev/nvme0n1 vendor: A-Data model: IM2P33F3 NVMe 512GB
size: 476.94 GiB speed: 31.6 Gb/s lanes: 4 serial: <filter> temp: 52.9 C
ID-2: /dev/sda vendor: Samsung model: SSD 870 EVO 500GB size: 465.76 GiB
speed: 6.0 Gb/s serial: <filter>
ID-3: /dev/sdb vendor: Western Digital model: WD10SDRW-11A0XS0
size: 931.48 GiB type: USB rev: 2.1 spd: 480 Mb/s lanes: 1 serial: <filter>
Partition:
ID-1: /boot size: 973.4 MiB used: 455.8 MiB (46.8%) fs: ext4 dev: /dev/sda2
ID-2: /boot/efi size: 598.8 MiB used: 13.3 MiB (2.2%) fs: vfat
dev: /dev/sda1
ID-3: /var size: 464.16 GiB used: 85.11 GiB (18.3%) fs: btrfs
dev: /dev/dm-0 mapped: luks-a79c02a1-318c-4e9b-9cff-ff6637c3e224
Swap:
ID-1: swap-1 type: zram size: 8 GiB used: 38 MiB (0.5%) priority: 100
dev: /dev/zram0
Sensors:
System Temperatures: cpu: 71.0 C pch: 67.0 C mobo: N/A
Fan Speeds (rpm): N/A
Info:
Memory: total: 16 GiB available: 15.46 GiB used: 4.87 GiB (31.5%)
Processes: 368 Power: uptime: 7d 16h 44m wakeups: 2 Init: systemd v: 255
target: graphical (5) default: graphical
Packages: pm: flatpak pkgs: 64 Compilers: N/A Shell: Bash v: 5.2.26
running-in: gnome-terminal inxi: 3.3.34
Please try to replicate your issue with these extensions disabled, and especially with Task Widget disabled, as it appears in stack traces right before 2 segfaults.
GNOME Shell dumped core 2 more times, on September 1st at 13:32:43 and 13:33:39. Do you remember using the system and being logged out forcefully at that time?
And a final question. I have noticed you are using the generic nouveau driver for the discrete GPU instead of the Nvidia drivers. Is there a reason for that? You can install the Nvidia drivers by following the instructions from RPM Fusion. There is also a section regarding installations on atomic desktops. Don’t skip the introductory part.
1 Like
sure, i will disable
this issue never happened with me using the system, i remember it happened during the day , eventually i screen lock and then when i come back i notice the issue
I though nouveau was the recommended way to handle nvidia when you do not need any intensive use of graphic cards, but i dont have any preferences, i also use secure boot on silverblue and i think is more difficult because of that
Since i disable task-widget i didnt have this issue. So i would certainly say task-widget is the culprit. Thanks.
May i ask you how do you analize the logs to discover the issue ?
1 Like
Read the logs and look at what happens at the time of, or a short time before, the error appears. This is a way of narrowing down the actual cause and may require trial and error to identify.
It takes time and experience to learn the troubleshooting techniques.
2 Likes