Random Freezes and unexplained boots

I have experienced random freezes for several years on different hardware and many different Fedora releases. This happens whether I’m actively using the system or the system is asleep. When the system freezes I’m not able to get a console from CTRL>ALT>F3-9 nor can I ssh into the system from any other system. My only recourse that I know of is to power cycle the system.

I’m not a laptop user so my only experience is with desktop systems. My current system is made up as so:

[root@odyssey: ~ ]
SU: # inxi -Fzx
System:
  Kernel: 5.19.14-100.fc35.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 2.37-25.fc35 Desktop: GNOME v: 41.9 Distro: Fedora release 35 (Thirty
    Five)
Machine:
  Type: Desktop Mobo: ASUSTeK model: ROG STRIX X570-E GAMING v: Rev X.0x
    serial: <filter> UEFI: American Megatrends v: 4403 date: 04/27/2022
Battery:
  Device-1: hidpp_battery_0 model: Logitech Wireless Keyboard K540/K545
    charge: 100% (should be ignored) status: discharging
  Device-2: hidpp_battery_1 model: Logitech Wireless Mouse charge: 55%
    (should be ignored) status: discharging
CPU:
  Info: 16-core model: AMD Ryzen 9 3950X bits: 64 type: MT MCP arch: Zen 2
    rev: 0 cache: L1: 1024 KiB L2: 8 MiB L3: 64 MiB
  Speed (MHz): avg: 2300 high: 3500 min/max: 2200/4761 boost: enabled
    cores: 1: 2200 2: 3500 3: 2200 4: 2200 5: 2200 6: 2200 7: 2200 8: 2200
    9: 2800 10: 2200 11: 3500 12: 2200 13: 2200 14: 2200 15: 2200 16: 2200
    17: 2200 18: 2200 19: 2200 20: 2200 21: 2200 22: 2200 23: 2200 24: 2200
    25: 2200 26: 2200 27: 2200 28: 2200 29: 2200 30: 2200 31: 2200 32: 2200
    bogomips: 223581
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
  Device-1: NVIDIA TU106 [GeForce GTX 1650] vendor: ASUSTeK driver: nvidia
    v: 515.76 arch: Turing bus-ID: 0a:00.0
  Display: server: X.Org v: 1.20.14 with: Xwayland v: 21.1.4 driver: X:
    loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa
    gpu: nvidia,nvidia-nvswitch resolution: 3840x2160~30Hz
  OpenGL: renderer: NVIDIA GeForce GTX 1650/PCIe/SSE2 v: 4.6.0 NVIDIA
    515.76 direct render: Yes
Audio:
  Device-1: NVIDIA TU106 High Definition Audio vendor: ASUSTeK
    driver: snd_hda_intel v: kernel bus-ID: 0a:00.1
  Device-2: AMD Starship/Matisse HD Audio vendor: ASUSTeK
    driver: snd_hda_intel v: kernel bus-ID: 0c:00.4
  Sound Server-1: ALSA v: k5.19.14-100.fc35.x86_64 running: yes
  Sound Server-2: PulseAudio v: 15.0 running: no
  Sound Server-3: PipeWire v: 0.3.56 running: yes
Network:
  Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel bus-ID: 04:00.0
  IF: wlp4s0 state: down mac: <filter>
  Device-2: Realtek RTL8125 2.5GbE vendor: ASUSTeK driver: r8169 v: kernel
    port: e000 bus-ID: 05:00.0
  IF: enp5s0 state: down mac: <filter>
  Device-3: Intel I211 Gigabit Network vendor: ASUSTeK driver: igb
    v: kernel port: d000 bus-ID: 06:00.0
  IF: enp6s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  IF-ID-1: virbr0 state: down mac: <filter>
Bluetooth:
  Device-1: Intel AX200 Bluetooth type: USB driver: btusb v: 0.8
    bus-ID: 1-6:3
  Report: rfkill ID: hci0 rfk-id: 0 state: up address: see --recommends
Drives:
  Local Storage: total: 8.19 TiB used: 1.96 TiB (23.9%)
  ID-1: /dev/nvme0n1 vendor: Corsair model: Force MP600 size: 931.51 GiB
    temp: 40.9 C
  ID-2: /dev/sda vendor: Seagate model: ST4000DM004-2CV104 size: 3.64 TiB
    temp: 31 C
  ID-3: /dev/sdb vendor: Seagate model: ST4000DM004-2CV104 size: 3.64 TiB
    temp: 29 C
Partition:
  ID-1: / size: 97.87 GiB used: 59.31 GiB (60.6%) fs: ext4
    dev: /dev/nvme0n1p3
  ID-2: /boot size: 769.8 MiB used: 254.3 MiB (33.0%) fs: ext4
    dev: /dev/nvme0n1p2
  ID-3: /boot/efi size: 249.7 MiB used: 14 MiB (5.6%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-4: /home size: 1.97 TiB used: 1.19 TiB (60.7%) fs: ext4 dev: /dev/sda1
Swap:
  ID-1: swap-1 type: partition size: 50 GiB used: 0 KiB (0.0%)
    dev: /dev/nvme0n1p4
  ID-2: swap-2 type: zram size: 8 GiB used: 0 KiB (0.0%) dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 30.0 C mobo: 32.0 C gpu: nvidia temp: 37 C
  Fan Speeds (RPM): N/A gpu: nvidia fan: 27%
Info:
  Processes: 548 Uptime: 46m Memory: 31.17 GiB used: 4.57 GiB (14.7%)
  Init: systemd target: graphical (5) Compilers: gcc: 11.3.1 clang: 13.0.1
  Packages: 32 note: see --rpm Shell: Bash v: 5.1.8 inxi: 3.3.21
[root@odyssey: ~ ]
SU: # 

I see the following in the logs after the system failed to wake up this morning.

Oct 11 17:10:50 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=
4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="syst
emd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 11 17:10:50 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4
294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="syste
md" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 11 17:10:50 odyssey systemd[1]: sysstat-collect.service: Deactivated success
fully.
Oct 11 17:10:50 odyssey systemd[1]: Finished system activity accounting tool.
-- Boot c3507aa5ce0a4678890a3757108eaa14 --
Oct 12 07:38:05 odyssey kernel: Linux version 5.19.14-100.fc35.x86_64 (mockbuild
@bkernel01.iad2.fedoraproject.org) (gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-3)
, GNU ld version 2.37-25.fc35) #1 SMP PREEMPT_DYNAMIC Wed Oct 5 21:52:15 UTC 202
2
Oct 12 07:38:05 odyssey kernel: Command line: BOOT_IMAGE=(hd3,gpt2)/vmlinuz-5.19
.14-100.fc35.x86_64 root=UUID=55dde26f-09d3-4e6f-aec5-c294f1b69f07 ro resume=UUI
D=a3270285-456e-4be9-b509-fabc88da146f rhgb quiet rd.driver.blacklist=nouveau mo
dprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platf
orm_driver_init
Oct 12 07:38:05 odyssey kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 fl
oating point registers'
Oct 12 07:38:05 odyssey kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE re
gisters'
Oct 12 07:38:05 odyssey kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX re
gisters'
Oct 12 07:38:05 odyssey kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]
:  256
Oct 12 07:38:05 odyssey kernel: x86/fpu: Enabled xstate features 0x7, context si
ze is 832 bytes, using 'compacted' format.
Oct 12 07:38:05 odyssey kernel: signal: max sigframe size: 1776
Oct 12 07:38:05 odyssey kernel: BIOS-provided physical RAM map:

This is confusing since the time indicated in the log is several hours off from when I power cycled the system. This applies to journalctl --list-boots or journalctl --no-pager|less. I grab what I think is the boot ID number and then search the log for it. That is what I have posted. There is a gap from Oct 11 17:10 to Oct 12 07:38. It was actually closer to 10:38 when I power cycled the system. Cron jobs don’t run during this gap…I don’t know but it looks as if the system is completely idle or the logs have been erased.

Sometimes when the system gets in this state it locks up both the wired ethernet connections and wifi connections across my entire local network. I can restore the local area network simply by unplugging my ethernet cable to the desktop.

I realize this is a hard problem to solve but I need help figuring out how to stop this. It has gone on like I said for many years.

I’m currently running kernel 5.19.14-100.fc35.x86_64, using x11, on gnome version 41.6.

Any help appreciated!
Edward

It looks like I have posted this twice! I got interrupted this morning and then couldn’t find it in the post so I did it again.

Maybe someone who know how can combine them.

Sorry for the inconvenience!

Happened again this morning!! System would not wake up, had to power cycle. Can anyone explain the time entries in the journal? I’m trying to relate these events to when things are happening on the system. This is the third day in a row I’ve had to power cycle.

If there are gaps in the logs, there might be some issue with saving them at the point it freezes up.

Do you have another system that remains on for the same time? if so, you can ssh from it to the freezing one, and run journalctl --follow to continuously track the logs. Hopefully this will enable you to see the problem, or at least the logs from around the time of the problem.

As I stated I can’t ssh into the system from any other system nor can I ping the IP address of the system. The only way I see the log I posted is after the system has been powered down and back up. I have pulled the power cord from the system and allowed the residual energy to subside (motherboard lights go out) before I plug the system back in. This same problem has been happening several years on at least 2 different hardware configurations.

Yes, I mean you have to ssh in and follow the logs before the problem happens, so that you can see if there are parts of the logs in the time gaps that are not saved correctly.

Ok, I miss understood what you meant! I have not tried that as my thought was that the logs would have priority and show things before the freeze. If I put the --follow in a file that will be a pretty big file. I’ll try it and see what happens.

If there’s a problem writing the logs to disk, then using --follow redirected to a file may also have that same problem. It may be better to leave it running and hope that the buffer on the remote computer is long enough to see the problem.

Well I had a failure to wake up this morning. In the log which I captured following your instructions this is what I see in the last 50 lines that cover approximately the last 30 minutes of system activity at least in the log.

[root@odyssey: ~ ]
SU: # tail -50 journal-101922.log 
Oct 19 19:24:14 odyssey systemd[1]: dnfdaemon.service: Consumed 1.173s CPU time.
Oct 19 19:30:01 odyssey systemd[1]: Starting system activity accounting tool...
Oct 19 19:30:01 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 19 19:30:01 odyssey systemd[1]: Finished system activity accounting tool.
Oct 19 19:30:01 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 19 19:30:01 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 19 19:40:01 odyssey systemd[1]: Starting system activity accounting tool...
Oct 19 19:40:01 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 19 19:40:01 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 19 19:40:01 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 19 19:40:01 odyssey systemd[1]: Finished system activity accounting tool.
Oct 19 19:50:01 odyssey systemd[1]: Starting system activity accounting tool...
Oct 19 19:50:01 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 19 19:50:01 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 19 19:50:01 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 19 19:50:01 odyssey systemd[1]: Finished system activity accounting tool.
Oct 19 19:52:00 odyssey systemd[1]: Starting dnf makecache...
Oct 19 19:52:01 odyssey dnf[24037]: Copr repo for PyCharm owned by phracek           27 kB/s | 3.6 kB     00:00
Oct 19 19:52:01 odyssey dnf[24037]: Dropbox Repository                               20 kB/s | 2.9 kB     00:00
Oct 19 19:52:01 odyssey dnf[24037]: Fedora 35 - x86_64                               55 kB/s |  22 kB     00:00
Oct 19 19:52:01 odyssey dnf[24037]: Fedora 35 openh264 (From Cisco) - x86_64        6.2 kB/s | 989  B     00:00
Oct 19 19:52:02 odyssey dnf[24037]: Fedora Modular 35 - x86_64                      109 kB/s |  22 kB     00:00
Oct 19 19:52:02 odyssey dnf[24037]: Fedora 35 - x86_64 - Updates                     83 kB/s |  16 kB     00:00
Oct 19 19:52:02 odyssey dnf[24037]: Fedora Modular 35 - x86_64 - Updates             97 kB/s |  21 kB     00:00
Oct 19 19:52:02 odyssey dnf[24037]: google-chrome                                    12 kB/s | 1.3 kB     00:00
Oct 19 19:52:03 odyssey dnf[24037]: Opera packages                                  3.4 kB/s | 3.0 kB     00:00
Oct 19 19:52:04 odyssey dnf[24037]: RPM Fusion for Fedora 35 - Free                 9.0 kB/s | 3.4 kB     00:00
Oct 19 19:52:04 odyssey dnf[24037]: RPM Fusion for Fedora 35 - Free tainted          13 kB/s | 3.2 kB     00:00
Oct 19 19:52:04 odyssey dnf[24037]: RPM Fusion for Fedora 35 - Free - Updates        13 kB/s | 3.0 kB     00:00
Oct 19 19:52:04 odyssey dnf[24037]: RPM Fusion for Fedora 35 - Nonfree               17 kB/s | 4.0 kB     00:00
Oct 19 19:52:05 odyssey dnf[24037]: RPM Fusion for Fedora 35 - Nonfree - NVIDIA Dri  16 kB/s | 3.8 kB     00:00
Oct 19 19:52:05 odyssey dnf[24037]: RPM Fusion for Fedora 35 - Nonfree - Steam       16 kB/s | 3.7 kB     00:00
Oct 19 19:52:05 odyssey dnf[24037]: RPM Fusion for Fedora 35 - Nonfree - Updates     14 kB/s | 3.3 kB     00:00
Oct 19 19:52:05 odyssey dnf[24037]: WineHQ packages                                  14 kB/s | 3.3 kB     00:00
Oct 19 19:52:06 odyssey dnf[24037]: Metadata cache created.
Oct 19 19:52:06 odyssey systemd[1]: dnf-makecache.service: Deactivated successfully.
Oct 19 19:52:06 odyssey systemd[1]: Finished dnf makecache.
Oct 19 19:52:06 odyssey systemd[1]: dnf-makecache.service: Consumed 1.062s CPU time.
Oct 19 19:52:06 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 19 19:52:06 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 19 20:00:01 odyssey systemd[1]: Starting system activity accounting tool...
Oct 19 20:00:01 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 19 20:00:01 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 19 20:00:01 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 19 20:00:01 odyssey systemd[1]: Finished system activity accounting tool.
Oct 19 20:01:01 odyssey CROND[24123]: (root) CMD (run-parts /etc/cron.hourly)
Oct 19 20:01:01 odyssey run-parts[24126]: (/etc/cron.hourly) starting 0anacron
Oct 19 20:01:01 odyssey run-parts[24132]: (/etc/cron.hourly) finished 0anacron
Oct 19 20:01:01 odyssey CROND[24122]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 19 20:07:03 odyssey cupsd[1319]: REQUEST localhost - - "POST / HTTP/1.1" 200 185 Renew-Subscription successful-ok
[root@odyssey: ~ ]
SU: # 

This doesn’t indicate anything but normal system activity, at least to me!

I had three days of no freezes or failures to wake up running on kernel 5.19.15-101.fc35.x86_64 but this failure to wake up is on 5.19.16-100.fc35.x86_64. It has brought back the problem I had posted about before about evolution and firefox causing by display to go dark for extended periods (60 sec - approx. 4 minutes). If I only run firefox everything appears to be OK (no display going dark) or if I only run evolution by itself I don’t see the display going dark. It like a complete failure of by video card suggesting and nvidia driver problem. But this was happening on the nouveau driver as well as the propriety driver. This may be another issue but to me they seem related.

Again any help appreciated.

I had another failure to wake up this morning. In the log capture I’m running it appears the last system log entry was Oct 26 11:32:58. The procedure I’m using is to ssh into problem system, su to root, and run this command: journalctl --follow |tee journal-102322.log.

The only difference I see is 3 additional log entries on the system used to run ssh. As evidence:

Oct 26 11:10:42 odyssey systemd[1]: Finished system activity accounting tool.
Oct 26 11:10:44 odyssey cupsd[1328]: REQUEST localhost - - "POST / HTTP/1.1" 200 185 Renew-Subscription successful-ok
Oct 26 11:20:42 odyssey systemd[1]: Starting system activity accounting tool...
Oct 26 11:20:42 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 26 11:20:42 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 26 11:20:42 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 26 11:20:42 odyssey systemd[1]: Finished system activity accounting tool.
Oct 26 11:30:42 odyssey systemd[1]: Starting system activity accounting tool...
Oct 26 11:30:42 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 26 11:30:42 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 26 11:30:42 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 26 11:30:42 odyssey systemd[1]: Finished system activity accounting tool.
Oct 26 11:32:58 odyssey systemd[1]: Starting Package management dnf daemon...
Oct 26 11:32:58 odyssey systemd[1]: Started Package management dnf daemon.
Oct 26 11:32:58 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnfdaemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
client_loop: send disconnect: Broken pipe
[edward@cyclops: ~ ]

In the file I’m teeing my output of journalctl --follow into this is what I see:

Oct 26 11:00:42 odyssey systemd[1]: Finished system activity accounting tool.
Oct 26 11:01:01 odyssey CROND[105153]: (root) CMD (run-parts /etc/cron.hourly)
Oct 26 11:01:01 odyssey run-parts[105156]: (/etc/cron.hourly) starting 0anacron
Oct 26 11:01:01 odyssey run-parts[105162]: (/etc/cron.hourly) finished 0anacron
Oct 26 11:01:01 odyssey CROND[105152]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 26 11:10:42 odyssey systemd[1]: Starting system activity accounting tool...
Oct 26 11:10:42 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 26 11:10:42 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 26 11:10:42 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 26 11:10:42 odyssey systemd[1]: Finished system activity accounting tool.
Oct 26 11:10:44 odyssey cupsd[1328]: REQUEST localhost - - "POST / HTTP/1.1" 200 185 Renew-Subscription successful-ok
Oct 26 11:20:42 odyssey systemd[1]: Starting system activity accounting tool...
Oct 26 11:20:42 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 26 11:20:42 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 26 11:20:42 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 26 11:20:42 odyssey systemd[1]: Finished system activity accounting tool.
Oct 26 11:30:42 odyssey systemd[1]: Starting system activity accounting tool...
Oct 26 11:30:42 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 26 11:30:42 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 26 11:30:42 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 26 11:30:42 odyssey systemd[1]: Finished system activity accounting tool.
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

I don’t know what happened other than when I tried to wake the system up , it wouldn’t. This is still on kernel 5.19.16-100.fc35.x86_64. Again hard power cycle, disk corruption that is fixed by fsck, hopefully I’m not corrupting file that I don’t use regularly. The only file corruption I have seen is a libreOffice spreadsheet that I was able to obtain from a backup copy and then add changes since last backup.

I’m not sure how to go about troubleshooting this, but there must be a way.

I’m in over my head and need help!!

Thanks in advance.
Edward

Another failure to wake up this morning. The system logs show just normal stuff and then stop. Cron jobs fail to execute after the time the system log stops documenting things. My ssh session terminates with a broken pipe. This is really frustrating!! There seems to be no way to actually track this down. Am I the only one seeing this type behavior or am I the only one running a desktop system that runs 24 x 7?? I’ve run linux systems long enough to remember people bragging about the number of days without a reboot. Now with the updates and recommendation to reboot after each, the freezes and so forth I rarely ever experience 3 days of uptime. Even when I’m away and the system is left alone the freezes/crashes always get it.

I am running the Fedora workstation product but have wondered if I should switch to the server product and load gnome desktop on it. Does anyone have an opinion if that would help? I guess my thinking is that maybe in the laptop world the product expects to be rebooted every night!

I have another system which I used to use that I don’t really use for anything except to experiment with that doesn’t ever experience this problem. It used to show this problem when it was my primary system that I would use evolution, firefox, libreoffice and various other applications on. It is running the exact same Fedora version and the same gnome desktop. I switched from using it because it is 12 years old and is slower. It was exhibiting the same crashes and freezes for years which led me to believe that it was hardware related so I built this state of the art (at least 1 1/2 years ago) system hoping to bypass this problem only to have it follow me. Now I’m sure it’s software!! But the frustration is how to track it down!!

My latest logs show:

Oct 29 20:10:57 odyssey systemd[1]: Starting system activity accounting tool...
Oct 29 20:10:57 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 20:10:57 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 20:10:57 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 29 20:10:57 odyssey systemd[1]: Finished system activity accounting tool.
Oct 29 20:20:57 odyssey systemd[1]: Starting system activity accounting tool...
Oct 29 20:20:57 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 20:20:57 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 20:20:57 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 29 20:20:57 odyssey systemd[1]: Finished system activity accounting tool.
Oct 29 20:30:57 odyssey systemd[1]: Starting system activity accounting tool...
Oct 29 20:30:57 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 20:30:57 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 20:30:57 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 29 20:30:57 odyssey systemd[1]: Finished system activity accounting tool.
Oct 29 20:40:57 odyssey systemd[1]: Starting system activity accounting tool...
Oct 29 20:40:57 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 20:40:57 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 20:40:57 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 29 20:40:57 odyssey systemd[1]: Finished system activity accounting tool.
Oct 29 20:43:59 odyssey cupsd[1325]: REQUEST localhost - - "POST / HTTP/1.1" 200 185 Renew-Subscription successful-ok
Oct 29 20:50:57 odyssey systemd[1]: Starting system activity accounting tool...
Oct 29 20:50:57 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 20:50:57 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 20:50:57 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 29 20:50:57 odyssey systemd[1]: Finished system activity accounting tool.
Oct 29 21:00:57 odyssey systemd[1]: Starting system activity accounting tool...
Oct 29 21:00:57 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 21:00:57 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 21:00:57 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 29 21:00:57 odyssey systemd[1]: Finished system activity accounting tool.
Oct 29 21:01:01 odyssey CROND[83189]: (root) CMD (run-parts /etc/cron.hourly)
Oct 29 21:01:01 odyssey run-parts[83192]: (/etc/cron.hourly) starting 0anacron
Oct 29 21:01:01 odyssey run-parts[83198]: (/etc/cron.hourly) finished 0anacron
Oct 29 21:01:01 odyssey CROND[83188]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 29 21:10:57 odyssey systemd[1]: Starting system activity accounting tool...
Oct 29 21:10:57 odyssey audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 21:10:57 odyssey audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 21:10:57 odyssey systemd[1]: sysstat-collect.service: Deactivated successfully.
Oct 29 21:10:57 odyssey systemd[1]: Finished system activity accounting tool.

Not that it is likely to help anyone.

I guess I’m not really expecting any help but thanks for letting me vent!!!

Most of us don’t experience the freezes you report.

The way to track down the cause is to do a clean new install and do not install anything extra, but do perform a full system upgrade.

Run the system that way for a day or two, and if it has no freezes that confirms it is not an OS issue.

After that time install one or two of the additional apps and again run for one or two days to see if the freezes occur or not. If they do then one of the apps just installed appear to be the cause.

If not, then rinse and repeat. Making sure to only add one or maybe 2 apps each time until either the system freezes or you have all desired additional packages installed. Make sure you allow adequate time for testing between installs so you can tell if the newly installed packages are the cause or not.

Go through the list of apps you want from fedora or fedora compatible repos until you have finished installing all from there then if desired install from other locations. Again following the same procedure.

If installing packages that you compile or from 3rd party repos and the freeze occurs then it is not a fedora issue but is directly related to the app that was just installed; and potential interactions between that app and already installed apps or the OS.

I know this sounds long and time consuming, and it may be. However, it is not possible to identify a cause without detailed testing to narrow down the possibilities. We cannot do that for you.

Thanks for your reply! First I’m almost 100% positive that it is not an OS issue. As I stated before my old system (where this happened on and off for years) no longer exhibits this problem and as far as packages the make up is identical. However, I’m not doing anything with this system except running updates every week or so. I use this system to test out new release upgrades (35 to 36 for example) before I run them on my active system.

I realize no one can “do this for me” but the purpose of the system is to allow me to do the things I need a computer for. This course of action will completely void any benefit of having a computer.

I’m not a novice linux user or a computer whiz, however I’m very experienced in computer operation and programming as that was my “day” job for approximately 30 years. I started as a system administrator on UNIX system in 1985 and continued on various UNIX varieties (HPUX, Solaris, etc.) until 2010. I have been running linux in one variety or another since 1996. This problem is so random that it seems to be related to a combination of OS/application releases. The problem is related to how the applications interact with gnome as that is the desktop shell I’m using. It can go weeks without happening then following some updates it may happen every couple of days for weeks.

I truly believe the problem is related to gnome, firefox, or evolution as these are the application I most frequently use.

In post on this forum I was only hoping to help the community in figuring out this issue but if I’m the only one experiencing it then I’ll take up no more of your time.

Thanks for any efforts folks have made in trying to help!!

Hi Edward Campbell, Hi All,
What are your latest findings on this?
Have you managed to fix the issue, or at least to progress?

I’m facing a similar issue. Also, I’m not so much surprised that Fedora crashes or hangs but I’m disappointed that it’s so complicated to see proper logs or troubleshoot.

Thanks for you update.

cheers, g.

To some degree it has improved, however still some new kernels have the same problems I saw. My problems now seem to be just associated with waking up from sleep. I have nvidia graphics so not sure if it’s related. I been told by those on this forum that I’m the only one having the problem but I still see post that are similar enough that I think it the same issue. Crashes are seldom for the whole system but I see some apps that still crash randomly. I use Fedora 40 with KDE exclusively for every thing I use a computer for. I have figured out how to make it workable with the switch to Wayland, but it’s still a long way from where X11 was in usability.

I have stopped upgrading when a new kernel is released and wait maybe a week or so then upgrade. I also upgrade flatpaks when I upgrade an new kernel, then do flatpaks update for the next several days since they seem to be a little slower getting things ready after a kernel upgrade.

It is difficult to find any information in the logs, especially for the failures to wake up. Typically I see no entries in the logs for hours before the attempt to wake up, but no errors.

I know this is not particularly helpful but it is what I’m seeing.

I find one-stop shopping for error messages with journalctl a big improvement over grep searches across multiple log files. Linux has, however, become much more complicated with the ever expanding range of hardware and use cases. Solving problems often depends on help from the community. Many Linux issues are shared across distros. If you can find relevant error messages, web searches may lead to a solution if you can filter out all the AI clickbait nonsense on today’s web.