Abrt-oops

Since a few days now I have this

Oct 18 09:00:17 kvm67kdocker.ada systemd[1]: Stopping ABRT kernel log watcher...
Oct 18 09:00:17 kvm67kdocker.ada systemd[1]: abrt-oops.service: Deactivated successfully.
Oct 18 09:00:17 kvm67kdocker.ada systemd[1]: Stopped ABRT kernel log watcher.
-- Boot 1364b8e6b9db4237852e2b78724c4eeb --
Oct 18 09:00:47 kvm67kdocker.ada systemd[1]: Started ABRT kernel log watcher.
Oct 19 10:48:55 kvm67kdocker.ada systemd[1]: Stopping ABRT kernel log watcher...
Oct 19 10:48:55 kvm67kdocker.ada systemd[1]: abrt-oops.service: Deactivated successfully.
Oct 19 10:48:55 kvm67kdocker.ada systemd[1]: Stopped ABRT kernel log watcher.
-- Boot 60aeda9cffe743fc8437c24041f01921 --
Oct 19 10:49:25 kvm67kdocker.ada systemd[1]: Started ABRT kernel log watcher.
-- Boot c8af9d94dc7f464ca541ab8c0aa7baa4 --
Oct 27 20:23:36 kvm67kdocker.ada systemd[1]: Started ABRT kernel log watcher.
Oct 27 20:23:38 kvm67kdocker.ada abrt-dump-journal-oops[1355]: abrt-dump-journal-oops: Cannot read journal data.
Oct 27 20:23:38 kvm67kdocker.ada systemd[1]: abrt-oops.service: Main process exited, code=exited, status=1/FAILURE
Oct 27 20:23:38 kvm67kdocker.ada systemd[1]: abrt-oops.service: Failed with result 'exit-code'.

Any ideas where I can find more substantial logs ?

to see why, the most obvious would be:

sudo systemctl status abrt-oops.service

Might be that you get an additional info.

No more info. It’s all the same.

sudo systemctl start abrt-oops.service 
or
sudo systemctl restart abrt-oops.service

No more message and the restart doesn’t give anymore info either. Always the same message in the journal to which is the same in the status of the process. « Cannot read journal data »

Sorry, for the moment out of ideas.

Hi, could you give the result of sudo grubby --info=ALL?

If your ABRT reporting about kernel again and again, maybe it’s a problem on boot command arguments.

I have similar problem (but not the same) in the past that ABRT reporting error on kernel-core each 2 or 3 seconds.

1 Like

Just upgraded to fedora server 35

index=0
kernel="/boot/vmlinuz-5.14.15-200.fc34.x86_64"
args="ro resume=/dev/mapper/fedora-swap rd.md.uuid=2288906c:a632e97e:62188968:fb280734 rd.md.uuid=98b1c9f2:748fa6b9:13fc9f6b:fa19834f rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/fedoravm rd.md.uuid=50e7918f:47e59639:82924552:f9287385 systemd.unified_cgroup_hierarchy=0 rhgb quiet"
root="UUID=ff61bb1b-c5cc-4acc-bf54-5327d416b1a0"
initrd="/boot/initramfs-5.14.15-200.fc34.x86_64.img"
title="Fedora (5.14.15-200.fc34.x86_64) 34 (Server Edition)"
id="59d1ccbf1e7e4845bf4a2983a4dd42d5-5.14.15-200.fc34.x86_64"
index=1
kernel="/boot/vmlinuz-5.14.14-300.fc35.x86_64"
args="ro resume=/dev/mapper/fedora-swap rd.md.uuid=2288906c:a632e97e:62188968:fb280734 rd.md.uuid=98b1c9f2:748fa6b9:13fc9f6b:fa19834f rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/fedoravm rd.md.uuid=50e7918f:47e59639:82924552:f9287385 systemd.unified_cgroup_hierarchy=0 rhgb quiet"
root="UUID=ff61bb1b-c5cc-4acc-bf54-5327d416b1a0"
initrd="/boot/initramfs-5.14.14-300.fc35.x86_64.img"
title="Fedora Linux (5.14.14-300.fc35.x86_64) 35 (Server Edition)"
id="59d1ccbf1e7e4845bf4a2983a4dd42d5-5.14.14-300.fc35.x86_64"
index=2
kernel="/boot/vmlinuz-5.14.14-200.fc34.x86_64"
args="ro resume=/dev/mapper/fedora-swap rd.md.uuid=2288906c:a632e97e:62188968:fb280734 rd.md.uuid=98b1c9f2:748fa6b9:13fc9f6b:fa19834f rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/fedoravm rd.md.uuid=50e7918f:47e59639:82924552:f9287385 systemd.unified_cgroup_hierarchy=0 rhgb quiet"
root="UUID=ff61bb1b-c5cc-4acc-bf54-5327d416b1a0"
initrd="/boot/initramfs-5.14.14-200.fc34.x86_64.img"
title="Fedora (5.14.14-200.fc34.x86_64) 34 (Server Edition)"
id="59d1ccbf1e7e4845bf4a2983a4dd42d5-5.14.14-200.fc34.x86_64"
index=3
kernel="/boot/vmlinuz-0-rescue-59d1ccbf1e7e4845bf4a2983a4dd42d5"
args="ro resume=/dev/mapper/fedora-swap rd.md.uuid=2288906c:a632e97e:62188968:fb280734 rd.md.uuid=98b1c9f2:748fa6b9:13fc9f6b:fa19834f rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/fedoravm rd.md.uuid=50e7918f:47e59639:82924552:f9287385 systemd.unified_cgroup_hierarchy=0 rhgb quiet crashkernel=auto"
root="UUID=ff61bb1b-c5cc-4acc-bf54-5327d416b1a0"
initrd="/boot/initramfs-0-rescue-59d1ccbf1e7e4845bf4a2983a4dd42d5.img"
title="Fedora (0-rescue-59d1ccbf1e7e4845bf4a2983a4dd42d5) 30 (Thirty)"
id="59d1ccbf1e7e4845bf4a2983a4dd42d5-0-rescue"

Still the same problem and i don’t know how it would be linked with with an error about read the logs. Would it change something if i erase the logs?

I have no experiences with LVM and RAID things.

But did you intentionally activate hibernate capabilities on your system?

Since there a resume paramater on your command args. As long as I understand the resume args is uses for pointing to boot to last stored session and this stored session usually on swap partition—disk partition and not zram things on RAM.

If the resume parameter pointing to wrong partition or pointing to zram things on RAM (that the stored session gone on power off) it could give an error messages on ABRT.

But I’m not sure with your case. Since I mentioned before that I don’t have experiences with LVM and RAID.

No it was at installation by default on fedora server installation.
So i’m not even sure why they are putting it by default

And i still don’t see the link with the cannot read logs error. You are focusing on the general fact that the service stop immediately and not the error message

In case you want to take a time for troubleshooting, you could temporarily change boot command args and this change will back to previous state when it’s reboot.

For a test, if you never did it before below are safest task to temporary remove Fedora loading screen on on boot and show running task by systemd.

  1. When you are presented with boot list on start up, press e on keyboard on one of any boot list presented.
  2. You’ll get some text. Find word rhgb and remove this rhgb only word.
  3. After that read at the very end line on your screen. It’s should mention to continue the boot by pressing CTRL+x.
  4. After that Fedora loading screen will gone and your display will show list of tasks by systemd.
  5. After you login and reboot you pc, your Fedora loading screen should be back again and rhgb parameter will present again.

If you comfortable with above method you could do the same by removing resume=/dev/mapper/fedora-swap and try to booting with above steps.

If your ABRT warning messages not present again by removing resume=/dev/mapper/fedora-swap, you could make it permanent with:

$ sudo grubby --remove-args="resume=/dev/mapper/fedora-swap" --update-kernel=ALL

Or you also can modify default grub file.

# Open with text editor with sudo
$ sudo nano /etc/default/grub

# Find and delete `resume=/dev/mapper/fedora-swap` part
# Save it with ctrl + x if you're using `nano` editor

# Update your grub
# For legacy bios system
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# For UEFI bios
$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Be careful with this advice!
For fedora 33 and earlier this is correct for an efi booting system.
For fedora 34 and later the command should be one of:

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
or
$ sudo grub2-mkconfig -o /etc/grub2.cfg
or
$ sudo grub2-mkconfig -o /etc/grub2-efi.cfg

All 3 commands have exactly the same effect regardless of whether booting in legacy mode or efi mode. Fedora 34 and later use a standard grub.cfg location.

1 Like

I read about proposal to changes the grub.cfg path like what you mentioned, but from official doc for Fedora 34 & 35 my terminal command still relevant.

Sources:

Fedora 34 Doc

Fedora 35 Doc

I understand. It appears that documentation has not kept up with the changes.

If you look at this you will see the correction.
https://fedoraproject.org/wiki/Changes/UnifyGrubConfig
I will post a message about the documentation updates needed.