With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
Suggestions?
John P
I also see frequent pop-ups saying kdeinit5 closed unexpectedly. Have not noticed any adverse effects, other than the pop-ups.
On Thu, Aug 29, 2019 at 6:51 AM John Pilkington johnpilk222@gmail.com wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
Suggestions?
John P _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Torsdag 29 augusti 2019 skrev Go Canes:
I also see frequent pop-ups saying kdeinit5 closed unexpectedly. Have not noticed any adverse effects, other than the pop-ups.
On Thu, Aug 29, 2019 at 6:51 AM John Pilkington johnpilk222@gmail.com wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
I also see this on my two machines with Fedora 29 since the upgrade of kf5-xx a few days ago. It seems to be related to when I close a window, for example Dolphin.
Best regards Jan Simonson
On 29/08/2019 22:10, Jan Simonson wrote:
Torsdag 29 augusti 2019 skrev Go Canes:
I also see frequent pop-ups saying kdeinit5 closed unexpectedly. Have not noticed any adverse effects, other than the pop-ups.
On Thu, Aug 29, 2019 at 6:51 AM John Pilkington johnpilk222@gmail.com wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
I also see this on my two machines with Fedora 29 since the upgrade of kf5-xx a few days ago. It seems to be related to when I close a window, for example Dolphin.
Best regards Jan Simonson
Thanks. I had seen a notification occasionally before, but found a row of sad faces at the bottom of the screen this morning. No other effects noticed.
John P
John Pilkington wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
I don't see how kannolo-root-unlocker would be causing this issue (and I wrote that package, and of course I have it installed).
Kevin Kofler
John Pilkington wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
I'm able to reproduce, but I'm at a loss where the problem comes from.
I tried building kf5-5.61.0 locally, and the problem remained.
I see it's been reported, https://bugzilla.redhat.com/show_bug.cgi?id=1746465 https://bugzilla.redhat.com/show_bug.cgi?id=1743895
and upstream at https://bugs.kde.org/show_bug.cgi?id=411441
-- Rex
Rex Dieter wrote:
John Pilkington wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
I'm able to reproduce, but I'm at a loss where the problem comes from.
I tried building kf5-5.61.0 locally, and the problem remained.
I see it's been reported, https://bugzilla.redhat.com/show_bug.cgi?id=1746465 https://bugzilla.redhat.com/show_bug.cgi?id=1743895
and upstream at https://bugs.kde.org/show_bug.cgi?id=411441
I think I've found one workaround, at least after some initial testing, if you set KDE_DEBUG=1 in your environment, which effectively disabled drkonqi crash reporter, then the kdeinit errors stop happening.
I set that in /etc/xdg/plasma-workspace/env/env.sh, adding the line: export KDE_DEBUG=1
-- Rex
Rex Dieter wrote:
Rex Dieter wrote:
John Pilkington wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
I'm able to reproduce, but I'm at a loss where the problem comes from.
I tried building kf5-5.61.0 locally, and the problem remained.
I see it's been reported, https://bugzilla.redhat.com/show_bug.cgi?id=1746465 https://bugzilla.redhat.com/show_bug.cgi?id=1743895
and upstream at https://bugs.kde.org/show_bug.cgi?id=411441
I think I've found one workaround, at least after some initial testing, if you set KDE_DEBUG=1 in your environment, which effectively disabled drkonqi crash reporter, then the kdeinit errors stop happening.
I set that in /etc/xdg/plasma-workspace/env/env.sh, adding the line: export KDE_DEBUG=1
So, that only hides the crashes, my journalctl still includes entries like Process ... (file.so) of user ... dumped core. Stack trace of thread ...: #0 0x000000000000 n/a (n/a)
-- Rex
On 30/08/2019 22:58, Rex Dieter wrote:
Rex Dieter wrote:
Rex Dieter wrote:
John Pilkington wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
I'm able to reproduce, but I'm at a loss where the problem comes from.
I tried building kf5-5.61.0 locally, and the problem remained.
I see it's been reported, https://bugzilla.redhat.com/show_bug.cgi?id=1746465 https://bugzilla.redhat.com/show_bug.cgi?id=1743895
and upstream at https://bugs.kde.org/show_bug.cgi?id=411441
I think I've found one workaround, at least after some initial testing, if you set KDE_DEBUG=1 in your environment, which effectively disabled drkonqi crash reporter, then the kdeinit errors stop happening.
I set that in /etc/xdg/plasma-workspace/env/env.sh, adding the line: export KDE_DEBUG=1
So, that only hides the crashes, my journalctl still includes entries like Process ... (file.so) of user ... dumped core. Stack trace of thread ...: #0 0x000000000000 n/a (n/a)
-- Rex
Thanks Rex: I don't know if this helps or is merely obvious, but I've just run
sudo journalctl --system -r | grep kdeinit5
and see
audit[xx] : ANOM_ABEND ... comm="file.so" ... every few minutes from Aug 28 22:33 to Aug 29 15:32
I'm not seeing them now - just org.freedesktop activations by dbus-daemon, I think for mythtv.
John
Rex Dieter wrote:
Rex Dieter wrote:
Rex Dieter wrote:
John Pilkington wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
I'm able to reproduce, but I'm at a loss where the problem comes from.
I tried building kf5-5.61.0 locally, and the problem remained.
I see it's been reported, https://bugzilla.redhat.com/show_bug.cgi?id=1746465 https://bugzilla.redhat.com/show_bug.cgi?id=1743895
and upstream at https://bugs.kde.org/show_bug.cgi?id=411441
I think I've found one workaround, at least after some initial testing, if you set KDE_DEBUG=1 in your environment, which effectively disabled drkonqi crash reporter, then the kdeinit errors stop happening.
I set that in /etc/xdg/plasma-workspace/env/env.sh, adding the line: export KDE_DEBUG=1
So, that only hides the crashes, my journalctl still includes entries like Process ... (file.so) of user ... dumped core. Stack trace of thread ...: #0 0x000000000000 n/a (n/a)
I'm officially out of ideas and have exhausted my developer-fu trying to make sense of these traces.
Any other ideas or suggestions?
-- Rex
On 03/09/2019 15:00, Rex Dieter wrote:
Rex Dieter wrote:
Rex Dieter wrote:
Rex Dieter wrote:
John Pilkington wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
I'm able to reproduce, but I'm at a loss where the problem comes from.
I tried building kf5-5.61.0 locally, and the problem remained.
I see it's been reported, https://bugzilla.redhat.com/show_bug.cgi?id=1746465 https://bugzilla.redhat.com/show_bug.cgi?id=1743895
and upstream at https://bugs.kde.org/show_bug.cgi?id=411441
I think I've found one workaround, at least after some initial testing, if you set KDE_DEBUG=1 in your environment, which effectively disabled drkonqi crash reporter, then the kdeinit errors stop happening.
I set that in /etc/xdg/plasma-workspace/env/env.sh, adding the line: export KDE_DEBUG=1
So, that only hides the crashes, my journalctl still includes entries like Process ... (file.so) of user ... dumped core. Stack trace of thread ...: #0 0x000000000000 n/a (n/a)
I'm officially out of ideas and have exhausted my developer-fu trying to make sense of these traces.
Any other ideas or suggestions?
-- Rex
Thanks for looking at this.
I'm not seeing the conttinuing repeats anymore, but can still provoke 2 instances by closing dolphin; mainly I use konqueror as FM. There was a bunch of kde-settings updates around the time the repeats stopped. FWIW I get a vaguely similar notification on booting kubuntu 18.04, and I still suspect it might have something to do with having used kdesu with konqueror, or maybe SystemSettings, in the past. ISTR that in 'buntu the apology comes from konq.
There's also something probably self-inflicted in my System Settings launcher, which can't find plasma-systemsettings. I can launch it from the search thingy.
John
On Tue, Sep 3, 2019 at 7:57 AM John Pilkington johnpilk222@gmail.com wrote:
On 03/09/2019 15:00, Rex Dieter wrote:
Rex Dieter wrote:
Rex Dieter wrote:
Rex Dieter wrote:
John Pilkington wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
I'm able to reproduce, but I'm at a loss where the problem comes from.
I tried building kf5-5.61.0 locally, and the problem remained.
I see it's been reported, https://bugzilla.redhat.com/show_bug.cgi?id=1746465 https://bugzilla.redhat.com/show_bug.cgi?id=1743895
and upstream at https://bugs.kde.org/show_bug.cgi?id=411441
I think I've found one workaround, at least after some initial testing, if you set KDE_DEBUG=1 in your environment, which effectively disabled drkonqi crash reporter, then the kdeinit errors stop happening.
I set that in /etc/xdg/plasma-workspace/env/env.sh, adding the line: export KDE_DEBUG=1
So, that only hides the crashes, my journalctl still includes entries like Process ... (file.so) of user ... dumped core. Stack trace of thread ...: #0 0x000000000000 n/a (n/a)
I'm officially out of ideas and have exhausted my developer-fu trying to make sense of these traces.
Any other ideas or suggestions?
-- Rex
Thanks for looking at this.
I'm not seeing the conttinuing repeats anymore, but can still provoke 2 instances by closing dolphin; mainly I use konqueror as FM. There was a bunch of kde-settings updates around the time the repeats stopped. FWIW I get a vaguely similar notification on booting kubuntu 18.04, and I still suspect it might have something to do with having used kdesu with konqueror, or maybe SystemSettings, in the past. ISTR that in 'buntu the apology comes from konq.
There's also something probably self-inflicted in my System Settings launcher, which can't find plasma-systemsettings. I can launch it from the search thingy.
John
Yep, closing dolphin produces the errors on demand :) Ya!! (That was only half sarcastic. Producing an error on demand helps debug alot) If I do that while running journalctl -f I get the following ---------- Sep 03 09:54:56 tlaptop kwin_x11[2342]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 28593, resource id: 132120582, major code: 15 (QueryTree), minor code: 0 Sep 03 09:54:56 tlaptop kwin_x11[2342]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 28680, resource id: 134217739, major code: 18 (ChangeProperty), minor code: 0 Sep 03 09:54:56 tlaptop kwin_x11[2342]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 28684, resource id: 132120593, major code: 18 (ChangeProperty), minor code: 0 Sep 03 09:54:56 tlaptop systemd[1]: Started Process Core Dump (PID 6655/UID 0). Sep 03 09:54:56 tlaptop systemd[1]: Started Process Core Dump (PID 6660/UID 0). Sep 03 09:54:56 tlaptop systemd[1]: Started Process Core Dump (PID 6664/UID 0). Sep 03 09:54:56 tlaptop plasmashell[2351]: QQuickItem::stackAfter: Cannot stack StatusNotifierItem_QMLTYPE_290(0x5559ad270a50, parent=0x5559a9c04560, geometry=0,0 0x0) after StatusNotifierItem_QMLTYPE_290(0x7f31500435e0), which must be a sibling Sep 03 09:54:56 tlaptop systemd-coredump[6662]: Process 6645 (file.so) of user 1000 dumped core.
Stack trace of thread 6645: #0 0x00007f34363cffa5 _ZN6QMutex4lockEv (libQt5Core.so.5) #1 0x00007f34365c17e6 _ZN10QTextCodec14codecForLocaleEv (libQt5Core.so.5) #2 0x00007f343644da09 _ZN7QString20fromLocal8Bit_helperEPKci (libQt5Core.so.5) #3 0x00007f3436521928 _ZN14QStandardPaths16writableLocationENS_16StandardLocationE (libQt5Core.so.5) #4 0x00007f3437fe5861 _ZL20startProcessInternaliPPKcbb (libKF5Crash.so.5) #5 0x00007f3437fe6322 _ZN6KCrash12startProcessEiPPKcb (libKF5Crash.so.5) #6 0x00007f3437fe67d5 _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5) #7 0x00007f343565e9c0 .annobin_sigaction.c (libc.so.6) ---------- and then the STace trace repeated twice more with just the begginning number changing.
Troy
On Tue, Sep 3, 2019 at 10:56 AM John Pilkington johnpilk222@gmail.com wrote:
still suspect it might have something to do with having used kdesu with
I don't use kdesu, at least not directly or that I know of, and I am seeing the issue. I think I mainly see it when closing Okular windows.
On 03/09/2019 19:07, Go Canes wrote:
On Tue, Sep 3, 2019 at 10:56 AM John Pilkington johnpilk222@gmail.com wrote:
still suspect it might have something to do with having used kdesu with
I don't use kdesu, at least not directly or that I know of, and I am seeing the issue.
OK, thanks. It was just a mildly non-standard aspect of my system that I thought I ought to mention.
I think I mainly see it when closing Okular
windows.
On 03/09/2019 12:07, Go Canes wrote:
On Tue, Sep 3, 2019 at 10:56 AM John Pilkington johnpilk222@gmail.com wrote:
still suspect it might have something to do with having used kdesu with
I don't use kdesu, at least not directly or that I know of, and I am seeing the issue. I think I mainly see it when closing Okular windows. _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
This is what my wife told me today as well. Gets the popup mainly with Okular.
Have not seen it in F30.
Will have to check the logs.
On 05/09/2019 06:21, Robin Laing wrote:
On 03/09/2019 12:07, Go Canes wrote:
On Tue, Sep 3, 2019 at 10:56 AM John Pilkington johnpilk222@gmail.com wrote:
still suspect it might have something to do with having used kdesu with
I don't use kdesu, at least not directly or that I know of, and I am seeing the issue. I think I mainly see it when closing Okular windows. _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
This is what my wife told me today as well. Gets the popup mainly with Okular.
Have not seen it in F30.
Will have to check the logs. _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
It is happing multiple times a day on our systems. I have seen it happen when just closing a Thunderbird or Firefox tab.
Terry
Before seeing this discussion I filled bugreport https://bugs.kde.org/show_bug.cgi?id=411610
Germano Massullo wrote:
Before seeing this discussion I filled bugreport https://bugs.kde.org/show_bug.cgi?id=411610
Looks like yet another QML use-after-free. Possibly the same one that has been plaguing the Plasma Kicker menu for months on F28 and F29. I wonder whether Qt 5.12 fixes it (which would explain why people are not seeing this on F30). So it might still be worth upgrading Qt on F29 after all.
Kevin Kofler
Germano Massullo wrote:
Before seeing this discussion I filled bugreport https://bugs.kde.org/show_bug.cgi?id=411610
Uh wait, your report *is* the plasmashell Kicker crash, completely unrelated to the kdeinit5 one. The Kicker crash has been there for months.
Kevin Kofler
Il giorno gio 5 set 2019 alle ore 14:06 Kevin Kofler kevin.kofler@chello.at ha scritto:
Germano Massullo wrote:
Before seeing this discussion I filled bugreport https://bugs.kde.org/show_bug.cgi?id=411610
Uh wait, your report *is* the plasmashell Kicker crash, completely unrelated to the kdeinit5 one. The Kicker crash has been there for months.
Ah, I was thinking about kdeinit5 because I got a lot of drkonqi popups about kdeinit5 crashes
Germano Massullo wrote:
Before seeing this discussion I filled bugreport https://bugs.kde.org/show_bug.cgi?id=411610
FYI, there's an upstream fix for this one: https://cgit.kde.org/plasma-desktop.git/commit/?id=9371a7c96d4722b93b49b18df... which should be backported to Fedora 29.
This is the fix for the annoying Kicker QML/model use-after-free bugs that have been there for months. It's fixed in Plasma ≥ 5.15 and Plasma 5.12 LTS, but Fedora 29 has Plasma 5.14.
Kevin Kofler
On 05/09/2019 09:09, Terry Barnaby wrote:
On 05/09/2019 06:21, Robin Laing wrote:
On 03/09/2019 12:07, Go Canes wrote:
On Tue, Sep 3, 2019 at 10:56 AM John Pilkington johnpilk222@gmail.com wrote:
still suspect it might have something to do with having used kdesu with
I don't use kdesu, at least not directly or that I know of, and I am seeing the issue. I think I mainly see it when closing Okular windows.
This is what my wife told me today as well. Gets the popup mainly with Okular.
Have not seen it in F30.
Will have to check the logs.
It is happing multiple times a day on our systems. I have seen it happen when just closing a Thunderbird or Firefox tab.
Terry
I said earlier that the repetitive form of this problem had gone away. It's now back, after the kernel and various firmare files were updated yesterday. I was away from the system this afternoon and found sad faces across the screen on my return. Does this help?
John P
sudo journalctl --system -r --since="2019-09-05 12:30:00" --until="2019-09-05 13:30:00" | tee /tmp/ANOM_ABEND.txt
-- Logs begin at Thu 2017-08-17 15:01:42 BST, end at Thu 2019-09-05 17:33:48 BST. -- Sep 05 13:27:26 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@44-6969-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:27:26 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@44-6969-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:27:26 HP_Fed systemd[1]: Started Process Core Dump (PID 6969/UID 0). Sep 05 13:27:26 HP_Fed audit[6951]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6951 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 13:22:55 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@43-6923-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:22:55 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@43-6923-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:22:55 HP_Fed systemd[1]: Started Process Core Dump (PID 6923/UID 0). Sep 05 13:22:55 HP_Fed audit[6912]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6912 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 13:18:24 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@42-6884-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:18:24 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@42-6884-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:18:24 HP_Fed systemd[1]: Started Process Core Dump (PID 6884/UID 0). Sep 05 13:18:24 HP_Fed audit[6875]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6875 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 13:13:53 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@41-6848-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:13:53 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@41-6848-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:13:53 HP_Fed systemd[1]: Started Process Core Dump (PID 6848/UID 0). Sep 05 13:13:53 HP_Fed audit[6833]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6833 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 13:09:22 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@40-6806-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:09:22 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@40-6806-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:09:22 HP_Fed systemd[1]: Started Process Core Dump (PID 6806/UID 0). Sep 05 13:09:22 HP_Fed audit[6799]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6799 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 13:07:00 HP_Fed cupsd[988]: REQUEST localhost - - "POST / HTTP/1.1" 200 183 Renew-Subscription successful-ok Sep 05 13:04:51 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@39-6771-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:04:51 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@39-6771-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:04:51 HP_Fed systemd[1]: Started Process Core Dump (PID 6771/UID 0). Sep 05 13:04:51 HP_Fed audit[6749]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6749 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 13:01:01 HP_Fed run-parts[6760]: (/etc/cron.hourly) finished 0anacron Sep 05 13:01:01 HP_Fed run-parts[6754]: (/etc/cron.hourly) starting 0anacron Sep 05 13:01:01 HP_Fed CROND[6751]: (root) CMD (run-parts /etc/cron.hourly) Sep 05 13:00:20 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@38-6722-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:00:20 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@38-6722-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 13:00:20 HP_Fed systemd[1]: Started Process Core Dump (PID 6722/UID 0). Sep 05 13:00:20 HP_Fed audit[6709]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6709 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 12:55:49 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@37-6681-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:55:49 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@37-6681-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:55:49 HP_Fed systemd[1]: Started Process Core Dump (PID 6681/UID 0). Sep 05 12:55:49 HP_Fed audit[6663]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6663 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 12:51:18 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@36-6634-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:51:18 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@36-6634-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:51:18 HP_Fed systemd[1]: Started Process Core Dump (PID 6634/UID 0). Sep 05 12:51:18 HP_Fed audit[6621]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6621 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 12:49:31 HP_Fed systemd[1]: Started dnf makecache. Sep 05 12:49:31 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:49:31 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:49:31 HP_Fed dnf[6629]: Metadata cache refreshed recently. Sep 05 12:49:30 HP_Fed systemd[1]: Starting dnf makecache... Sep 05 12:46:47 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@35-6594-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:46:47 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@35-6594-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:46:47 HP_Fed systemd[1]: Started Process Core Dump (PID 6594/UID 0). Sep 05 12:46:47 HP_Fed audit[6582]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6582 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 12:42:16 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@34-6554-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:42:16 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@34-6554-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:42:16 HP_Fed systemd[1]: Started Process Core Dump (PID 6554/UID 0). Sep 05 12:42:16 HP_Fed audit[6541]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6541 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 12:37:45 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@33-6513-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:37:45 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@33-6513-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:37:45 HP_Fed systemd[1]: Started Process Core Dump (PID 6513/UID 0). Sep 05 12:37:45 HP_Fed audit[6502]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6502 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 12:33:14 HP_Fed audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@32-6474-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:33:14 HP_Fed audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@32-6474-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 05 12:33:14 HP_Fed systemd[1]: Started Process Core Dump (PID 6474/UID 0). Sep 05 12:33:14 HP_Fed audit[6461]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=6461 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1
I said earlier that the repetitive form of this problem had gone away. It's now back, after the kernel and various firmare files were updated yesterday. I was away from the system this afternoon and found sad faces across the screen on my return. Does this help?
John P
sudo journalctl --system -r --since="2019-09-05 12:30:00" --until="2019-09-05 13:30:00" | tee /tmp/ANOM_ABEND.txt ................
I'm afraid I got misled by the -r there, which puts the log in reverse and was inherited from an earlier command line. So the core dumps follow the event... Sorry.
On 29/08/2019 04:49, John Pilkington wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
Suggestions?
John Pct.org
With this, I find that there are error messages going back to Aug 27. No constant time frame.
sudo journalctl --system -r |grep -i kdeinit5 |grep crash
Sep 05 17:26:55 XXX abrt-notification[17946]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 17:12:48 XXX abrt-notification[17475]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 17:02:49 XXX abrt-notification[17256]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 17:02:49 XXX abrt-notification[17210]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 16:52:58 XXX abrt-notification[16579]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 16:50:55 XXX abrt-notification[16481]: Process 11436 (kdeinit5) crashed in QMutex::lock()()
----------------------------- If I drop the crash I get this. Does this point to a SELINUX issue? ------------------------------------
Sep 05 21:40:09 XXX abrt-notification[21238]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:40:08 XXX abrt-notification[21191]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:40:07 XXX audit[20880]: ANOM_ABEND auid=1101 uid=1101 gid=1101 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=20880 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 21:40:07 XXX audit[20879]: ANOM_ABEND auid=1101 uid=1101 gid=1101 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=20879 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 21:39:32 XXX abrt-notification[21043]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:39:30 XXX audit[20950]: ANOM_ABEND auid=1101 uid=1101 gid=1101 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=20950 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1
------------------------------------- I have only one error message in the Alert Browser. --------------------------------
SELinux is preventing abrt-action-sav from write access on the file .dbenv.lock.
Plugin: catchall SELinux denied access requested by abrt-action-sav. It is not expected that this access is required by abrt-action-sav and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
------------------------------------ sudo journalctl --system -r |grep abrt |less
Sep 05 21:48:16 XXX abrt-notification[21660]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:48:15 XXX abrt-server[21562]: Deleting problem directory ccpp-2019-09-05-21:48:14.903536-21350 (dup of ccpp-2019-08-28-21:15:37.821761-11436) Sep 05 21:48:15 XXX abrt-notification[21614]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:48:15 XXX abrt-server[21558]: Deleting problem directory ccpp-2019-09-05-21:48:14.879242-21362 (dup of ccpp-2019-08-28-21:15:37.821761-11436) Sep 05 21:48:14 XXX dbus-daemon[1222]: [system] Activating service name='org.freedesktop.problems' requested by ':1.1304' (uid=0 pid=21561 comm="/usr/bin/python3 /usr/bin/abrt-action-notify -d /v" label="system_u:system_r:abrt_t:s0-s0:c0.c1023") (using servicehelper)
-------------------------------- Directory ccpp-2019-08-28-21:15:37.821761-11436/ exists but ccpp-2019-09-05-21:48:14.879242-21362 doesn't exist at the time of this writing.l
What is also strange that in the /var/spool/abrt, all the directories have the same date displayed for ls -l except last-via-server and last-ccpp
Don't know if this is helpful or not but it is what I found.
Robin
On 05/09/2019 22:05, Robin Laing wrote:
On 29/08/2019 04:49, John Pilkington wrote:
With fully updated F29 I'm suddenly seeing this. 'Please report' but reporting and debugging seem broken for this. I wonder if it's related to historic enabling of kdesu and perhaps the kannolo repo?
Suggestions?
John Pct.org
With this, I find that there are error messages going back to Aug 27. No constant time frame.
sudo journalctl --system -r |grep -i kdeinit5 |grep crash
Sep 05 17:26:55 XXX abrt-notification[17946]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 17:12:48 XXX abrt-notification[17475]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 17:02:49 XXX abrt-notification[17256]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 17:02:49 XXX abrt-notification[17210]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 16:52:58 XXX abrt-notification[16579]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 16:50:55 XXX abrt-notification[16481]: Process 11436 (kdeinit5) crashed in QMutex::lock()()
----------------------------- If I drop the crash I get this. Does this point to a SELINUX issue? ------------------------------------
Sep 05 21:40:09 XXX abrt-notification[21238]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:40:08 XXX abrt-notification[21191]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:40:07 XXX audit[20880]: ANOM_ABEND auid=1101 uid=1101 gid=1101 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=20880 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 21:40:07 XXX audit[20879]: ANOM_ABEND auid=1101 uid=1101 gid=1101 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=20879 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1 Sep 05 21:39:32 XXX abrt-notification[21043]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:39:30 XXX audit[20950]: ANOM_ABEND auid=1101 uid=1101 gid=1101 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=20950 comm="file.so" exe="/usr/bin/kdeinit5" sig=11 res=1
------------------------------------- I have only one error message in the Alert Browser. --------------------------------
SELinux is preventing abrt-action-sav from write access on the file .dbenv.lock.
Plugin: catchall SELinux denied access requested by abrt-action-sav. It is not expected that this access is required by abrt-action-sav and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
------------------------------------ sudo journalctl --system -r |grep abrt |less
Sep 05 21:48:16 XXX abrt-notification[21660]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:48:15 XXX abrt-server[21562]: Deleting problem directory ccpp-2019-09-05-21:48:14.903536-21350 (dup of ccpp-2019-08-28-21:15:37.821761-11436) Sep 05 21:48:15 XXX abrt-notification[21614]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:48:15 XXX abrt-server[21558]: Deleting problem directory ccpp-2019-09-05-21:48:14.879242-21362 (dup of ccpp-2019-08-28-21:15:37.821761-11436) Sep 05 21:48:14 XXX dbus-daemon[1222]: [system] Activating service name='org.freedesktop.problems' requested by ':1.1304' (uid=0 pid=21561 comm="/usr/bin/python3 /usr/bin/abrt-action-notify -d /v" label="system_u:system_r:abrt_t:s0-s0:c0.c1023") (using servicehelper)
-------------------------------- Directory ccpp-2019-08-28-21:15:37.821761-11436/ exists but ccpp-2019-09-05-21:48:14.879242-21362 doesn't exist at the time of this writing.l
What is also strange that in the /var/spool/abrt, all the directories have the same date displayed for ls -l except last-via-server and last-ccpp
Don't know if this is helpful or not but it is what I found.
Robin
kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Just to add to the thread. Found this.
sudo systemctl status abrtd.service pam_mount password: ● abrtd.service - ABRT Automated Bug Reporting Tool Loaded: loaded (/usr/lib/systemd/system/abrtd.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2019-09-05 12:00:15 MDT; 10h ago Process: 1232 ExecStartPre=/usr/bin/bash -c pkill abrt-dbus || : (code=exited, status=0/SUCCESS) Main PID: 1261 (abrtd) Tasks: 3 (limit: 4915) Memory: 105.4M CGroup: /system.slice/abrtd.service └─1261 /usr/sbin/abrtd -d -s
Sep 05 21:40:09 XXX abrt-notification[21238]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:48:14 XXX abrt-server[21511]: Deleting problem directory ccpp-2019-09-05-21:48:14.388109-21340 (dup of cc> Sep 05 21:48:15 XXX abrt-server[21558]: Deleting problem directory ccpp-2019-09-05-21:48:14.879242-21362 (dup of cc> Sep 05 21:48:15 XXX abrt-notification[21614]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:48:15 XXX abrt-server[21562]: Deleting problem directory ccpp-2019-09-05-21:48:14.903536-21350 (dup of cc> Sep 05 21:48:16 XXX abrt-notification[21660]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:58:43 XXX abrt-server[21965]: Deleting problem directory ccpp-2019-09-05-21:58:43.459910-21788 (dup of cc> Sep 05 21:58:44 XXX abrt-notification[22016]: Process 11436 (kdeinit5) crashed in QMutex::lock()() Sep 05 21:58:44 XXX abrt-server[21966]: Deleting problem directory ccpp-2019-09-05-21:58:43.471181-21789 (dup of cc> Sep 05 21:58:44 XXX abrt-notification[22062]: Process 11436 (kdeinit5) crashed in QMutex::lock()()
sudo systemctl status abrt-ccpp.service ● abrt-ccpp.service - Install ABRT coredump hook Loaded: loaded (/usr/lib/systemd/system/abrt-ccpp.service; disabled; vendor preset: disabled) Active: inactive (dead)
udo systemctl status abrt-ccpp.service ● abrt-ccpp.service - Install ABRT coredump hook Loaded: loaded (/usr/lib/systemd/system/abrt-ccpp.service; disabled; vendor preset: disabled) Active: inactive (dead)
On 06/09/2019 05:10, Robin Laing wrote:
sudo systemctl status abrtd.service pam_mount password: ● abrtd.service - ABRT Automated Bug Reporting Tool Loaded: loaded (/usr/lib/systemd/system/abrtd.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2019-09-05 12:00:15 MDT; 10h ago Process: 1232 ExecStartPre=/usr/bin/bash -c pkill abrt-dbus || : (code=exited, status=0/SUCCESS) Main PID: 1261 (abrtd) Tasks: 3 (limit: 4915) Memory: 105.4M CGroup: /system.slice/abrtd.service └─1261 /usr/sbin/abrtd -d -s
I don't see crashes, but I'm still getting the notifications, the last a minute ago. It looks as if my ABRT is failing on boot:
[john@HP_Fed ~]$ date Fri 6 Sep 12:42:07 BST 2019 [john@HP_Fed ~]$ sudo systemctl status abrtd.service ● abrtd.service - ABRT Automated Bug Reporting Tool Loaded: loaded (/usr/lib/systemd/system/abrtd.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Wed 2019-09-04 21:32:35 BST; 1 day 15h ago Process: 937 ExecStart=/usr/sbin/abrtd -d -s (code=killed, signal=KILL) Process: 897 ExecStartPre=/usr/bin/bash -c pkill abrt-dbus || : (code=exited, status=0/SUCCESS) Main PID: 937 (code=killed, signal=KILL)
Sep 04 21:29:23 HP_Fed systemd[1]: Starting ABRT Automated Bug Reporting Tool... Sep 04 21:31:05 HP_Fed systemd[1]: abrtd.service: Start operation timed out. Terminating. Sep 04 21:31:29 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2018-02-22-22:12:33-1143-2' is not a problem directory Sep 04 21:31:48 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2018-02-22-22:12:33-1143-1' is not a problem directory Sep 04 21:31:49 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2016-06-15-11:47:06-940-0' is not a problem directory Sep 04 21:32:35 HP_Fed systemd[1]: abrtd.service: State 'stop-sigterm' timed out. Killing. Sep 04 21:32:35 HP_Fed systemd[1]: abrtd.service: Killing process 937 (abrtd) with signal SIGKILL. Sep 04 21:32:35 HP_Fed systemd[1]: abrtd.service: Main process exited, code=killed, status=9/KILL Sep 04 21:32:35 HP_Fed systemd[1]: abrtd.service: Failed with result 'timeout'. Sep 04 21:32:35 HP_Fed systemd[1]: Failed to start ABRT Automated Bug Reporting Tool. [john@HP_Fed ~]$
Sep 04 21:31:29 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2018-02-22-22:12:33-1143-2' is not a problem directory Sep 04 21:31:48 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2018-02-22-22:12:33-1143-1' is not a problem directory Sep 04 21:31:49 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2016-06-15-11:47:06-940-0' is not a problem directory
I'm not sure what this means, but /var/spool/oops is readable as root and contains 1859 directories. The last one was created under F28 on 2019-03-26
Sep 04 21:31:29 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2018-02-22-22:12:33-1143-2' is not a problem directory Sep 04 21:31:48 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2018-02-22-22:12:33-1143-1' is not a problem directory Sep 04 21:31:49 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2016-06-15-11:47:06-940-0' is not a problem directory
I'm not sure what that means, but /var/spool/abrt/ is readable by root and contains 1859 mainly oops* directories. The last one was created under F28 on 2019-03-26 -----------------
Those 3 directories were identified by sudo systemctl status abrtd.service
Krusader-as-root says that all the files in them are 0 bytes.
Other /var/spool/abrt/oops* directories that I have looked at have files of non-zero length.
In my SL7.7 box the last oops* directory is oops-2018-12-07-20:11:23-3913-0
That has non-zero length files too.
Sep 04 21:31:29 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2018-02-22-22:12:33-1143-2' is not a problem directory Sep 04 21:31:48 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2018-02-22-22:12:33-1143-1' is not a problem directory Sep 04 21:31:49 HP_Fed abrtd[937]: '/var/spool/abrt/oops-2016-06-15-11:47:06-940-0' is not a problem directory
I'm not sure what that means, but /var/spool/abrt/ is readable by root and contains 1859 mainly oops* directories. The last one was created under F28 on 2019-03-26 -----------------
Those 3 directories were identified by sudo systemctl status abrtd.service
Krusader-as-root says that all the files in them are 0 bytes.
Other /var/spool/abrt/oops* directories that I have looked at have files of non-zero length.
In my SL7.7 box the last oops* directory is oops-2018-12-07-20:11:23-3913-0
That has non-zero length files too.
------------------
The repetitive kdeinit5 closing was last seen at 21:22 yesterday.
At 21:46 systemd-tmpfiles reported:
[john@HP_Fed rpm]$ sudo journalctl --system --since="2019-09-06 20:30:00" | grep systemd-tmpfiles Sep 06 21:46:10 HP_Fed systemd-tmpfiles[9256]: [/usr/lib/tmpfiles.d/lirc.conf:1] Line references path below legacy directory /var/run/, updating /var/run/lirc → /run/lirc; please update the tmpfiles.d/ drop-in file accordingly. Sep 06 21:46:10 HP_Fed systemd-tmpfiles[9256]: [/usr/lib/tmpfiles.d/mdadm.conf:1] Line references path below legacy directory /var/run/, updating /var/run/mdadm → /run/mdadm; please update the tmpfiles.d/ drop-in file accordingly. Sep 06 21:46:10 HP_Fed systemd-tmpfiles[9256]: [/usr/lib/tmpfiles.d/pptp.conf:1] Line references path below legacy directory /var/run/, updating /var/run/pptp → /run/pptp; please update the tmpfiles.d/ drop-in file accordingly. Sep 06 21:46:10 HP_Fed systemd-tmpfiles[9256]: [/usr/lib/tmpfiles.d/sddm.conf:1] Line references path below legacy directory /var/run/, updating /var/run/sddm → /run/sddm; please update the tmpfiles.d/ drop-in file accordingly. Sep 06 21:46:10 HP_Fed systemd-tmpfiles[9256]: [/usr/lib/tmpfiles.d/xl2tpd.conf:1] Line references path below legacy directory /var/run/, updating /var/run/xl2tpd → /run/xl2tpd; please update the tmpfiles.d/ drop-in file accordingly.
I will do that...