Fedora Restarts by itself

Hello All,

I’m having this weird behavior where fedora just restarts by itself.
Mostly it restarts once a day but on some ocassion 2 or 3 restarts.

I have updated all drivers and packages i can think of

This does not happen when i installed UBUNTU or LINUX Mint on the Device.
Currently Fedora is all

NAME="Fedora Linux"
VERSION="35 (Workstation Edition)"
ID=fedora
VERSION_ID=35
VERSION_CODENAME=""
PLATFORM_ID="platform:f35"
PRETTY_NAME="Fedora Linux 35 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:35"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f35/system-administrators-guide/"
SUPPORT_URL="https://discussion.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=35
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=35
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation

Here is my Hardware info

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         39 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  8
  On-line CPU(s) list:   0-7
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz
    CPU family:          6
    Model:               158
    Thread(s) per core:  1
    Core(s) per socket:  8
    Socket(s):           1
    Stepping:            13
    CPU max MHz:         4700.0000
    CPU min MHz:         800.0000
    BogoMIPS:            6000.00
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdts
                         cp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx e
                         st tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefe
                         tch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx
                         2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_
                         window hwp_epp md_clear flush_l1d arch_capabilities
Virtualization features: 
  Virtualization:        VT-x
Caches (sum of all):     
  L1d:                   256 KiB (8 instances)
  L1i:                   256 KiB (8 instances)
  L2:                    2 MiB (8 instances)
  L3:                    12 MiB (1 instance)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-7
Vulnerabilities:         
  Itlb multihit:         KVM: Mitigation: VMX disabled
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
  Srbds:                 Mitigation; TSX disabled
  Tsx async abort:       Mitigation; TSX disabled

I’m using it for web Development. It gets irritating sometimes when you’re working then suddenly it restarts, the momentum is Gone.

Does any one had a simillar issue? i was trying to search the forums but no restart or reboot questions are the same as mine.

You need to check the logs and find out what triggers the restart.

3 Likes

The most common things that would trigger this are critically low battery or overheating. It might be good to use something like gkrellm to monitor your temperature internals. I’ve also had cases where I’ve plugged my laptop into a socket that was only active when a light switch was on, so it was draining over night when the light was turned off.

1 Like

The logs will reveal it :slight_smile:

When the machine reboots unintentionally the next time, check sudo journalctl --boot=-1 , which will show you all logs of the last boot (thus, logs of the boot that ended up with an unintentionally reboot). Go to the end of the logs (the last minute before the “–boot=-1” logs end) and check out what happened. If you are not sure how to interpret that, feel free to show us these logs. The last two minutes of the “–boot=-1”-logs should be sufficient to be sure that everything related is contained.

These are definitely realistic possibilities. However, I suggest checking the logs first before taking any action. Temperature and battery issues are contained in the logs.

2 Likes

Thank You. And sorry for the late reply

I have been waiting For the System to reboot for sometime.
I can’t make out what the error on the LOG is but it has something to do with DOCKER or the GNOME SHELL Crashing because that’s the only error i have when a ran the command you have given, and checked the timestamp with the exact reboot

Will make more test. After the couple of updates from Fedora it does not reboot

i will post some of my log here after it reboots again.

Thank you. The Journal itself is helpful to the tech side.
But for starters like me its a pain to read it.

Buit for now i have checked the command and it shows 2 Things Docker and GNOME SHELL WINDOW Crashing. Maybe because of noviou drivers? I’m not sure.

It does not frequently crash now after couple of updates but will check again

This is why I suggested to show us the journal :slight_smile:

Without further information (such as the logs of the journal), I am also not able to tell you much about the issue. An issue like this can have multiple origins. Detailed information of what is happening on the system is necessary.

1 Like

Thanks For Being there.

I have recently updated to Fedora 36. I hope that the issue will not be exist here.

I will update you if the problem exists. and will dump the journal log
will these command be correct, and will it contain the error in case?

journalctl --list-boots
journalctl -b {id}

i’m having trouble with the sudo journalctl --boot=-1 it has to many entries and i need to scroll to the current date to get to the current boot date.

thank you

1 Like

That would be better done as your regular user and using journalctl -b -1. Journalctl does not require the use of sudo.
If you want the output to a file do it as journalctl -b -1 > yourfilename

1 Like

You can run ‘problem reporting’ (abrt) application and see it maybe some package stop to work etc gnome shell or …