5:49 a.m.
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
2:57 p.m.
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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to kde-leave(a)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
4:10 p.m.
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(a)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
4:22 p.m.
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
4:26 p.m.
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(a)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
2:37 p.m.
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
4:51 p.m.
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
4:58 p.m.
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
6:19 p.m.
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
9 a.m.
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
9:56 a.m.
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
11:59 a.m.
On Tue, Sep 3, 2019 at 7:57 AM John Pilkington <johnpilk222(a)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
1:07 p.m.
On Tue, Sep 3, 2019 at 10:56 AM John Pilkington <johnpilk222(a)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.
2:11 p.m.
On 03/09/2019 19:07, Go Canes wrote:
On Tue, Sep 3, 2019 at 10:56 AM John Pilkington
<johnpilk222(a)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.
12:21 a.m.
On 03/09/2019 12:07, Go Canes wrote:
On Tue, Sep 3, 2019 at 10:56 AM John Pilkington
<johnpilk222(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)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.
3:09 a.m.
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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to kde-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)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
4:33 a.m.
Before seeing this discussion I filled bugreport
https://bugs.kde.org/show_bug.cgi?id=411610
7 a.m.
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
7:02 a.m.
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
7:10 a.m.
Il giorno gio 5 set 2019 alle ore 14:06 Kevin Kofler
<kevin.kofler(a)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
8:20 a.m.
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=9371a7c96d4722b93b49b1...
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
11:59 a.m.
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(a)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
12:20 p.m.
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.
11:05 p.m.
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
11:10 p.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)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)
6:53 a.m.
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 ~]$
8:37 a.m.
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
6:17 p.m.
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.
4:18 a.m.
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...
1687
days inactive
1696
days old
28 comments
9 participants
participants (9)
-
Germano Massullo -
Go Canes -
Jan Simonson -
John Pilkington -
Kevin Kofler -
Rex Dieter -
Robin Laing -
Terry Barnaby -
Troy Dawson