Bug 16396 - MCC won't start after logging out/in to KDE session - session recognised by polkit as "online" vs. "active"
Summary: MCC won't start after logging out/in to KDE session - session recognised by p...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal minor
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA5-64-OK advisory
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2015-07-17 04:15 CEST by John L. ten Wolde
Modified: 2019-08-29 14:17 CEST (History)
13 users (show)

See Also:
Source RPM: systemd-217-11.mga5
CVE:
Status comment:


Attachments

Description John L. ten Wolde 2015-07-17 04:15:48 CEST
In Mageia 5, after logging out and then back in to a KDE user session MCC (drakconf) can no be started by the user because the authentication GUI will no longer appear.

This issue very much resembles the one claimed to have been resolved in Bug 11184, though I'm filing this one against KDE.  Attempting to start drakconf via cli results in:

[john@purgatory ~]$ drakconf
Error executing command as another user: Not authorized

This incident has been reported.

---

The above resembles the behaviour described by Frank Griffin in Bug 12572, however no remote login/ssh is involved.


How reproducible:  Always.  Tested on both i586 and x86_64.


Steps to Reproduce:

1. Cold boot a Mageia 5 box and log into KDE.  Attempt to start drakconf.  All will appear to be functioning as expected.  You will be prompted for the root password.

2. Log out of that user and back in.  Do as in step #1 above, but now the launcher icon fails to respond and the CLI will report "Not authorized".

3. If another user id is available on the system, log out of the first user and in as the second user.  drakconf WILL start normally for the second user.

4. Log out of the second user and back in as either user.  drakconf will NOW FAIL to authenticate for both.


polkit packages installed:

lib64polkit1_0-0.113-1.mga5
polkit-kde-agent-1-0.99.1-2.mga5
lib64mate-polkit1_0-1.8.0-6.mga5
lib64polkit-qt-agent-1_1-0.112.0-6.mga5
mate-polkit-1.8.0-6.mga5
polkit-0.113-1.mga5
lib64polkit-qt-core-1_1-0.112.0-6.mga5
lib64polkit-gir1.0-0.113-1.mga5

Reproducible: 

Steps to Reproduce:
Comment 1 John L. ten Wolde 2015-07-17 04:22:23 CEST
@Colin Guthrie

Apologies if I appear presumptuous, but I'm adding you to the CC list because you seemed to have had ever so much fun working through those apparently similar (and possibly related) bugs I mentioned in Comment 1.

Thank you for your attention.

CC: (none) => johnltw, mageia

Comment 2 Morgan Leijström 2015-08-21 03:17:56 CEST
Duplicate of https://bugs.mageia.org/show_bug.cgi?id=13051 ?

I am getting this too.
Suspend/resume seem to trig this too.

CC: (none) => fri

Comment 3 Luc Menut 2015-08-28 09:30:40 CEST
(In reply to Morgan Leijström from comment #2)
> Duplicate of https://bugs.mageia.org/show_bug.cgi?id=13051 ?
> 
I don't think so. IMHO, this is another issue.


@all, when authentication fails, could you report the output of
  cat /run/systemd/users/$(id -u)

CC: (none) => lmenut

Comment 4 Henk Elbers 2015-08-28 17:38:03 CEST
same problem with MATE. Also clicking on the mageia online applet doesn't work.

$ cat /run/systemd/users/$(id -u)
# This is private data. Do not parse.
NAME=henk
STATE=online
RUNTIME=/run/user/500
SERVICE=user@500.service
SLICE=user-500.slice
DISPLAY=c4
REALTIME=1440774533171447
MONOTONIC=186129244
SESSIONS=c4 c3
SEATS=seat0 seat0
ACTIVE_SESSIONS=c4
ONLINE_SESSIONS=c4
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0

CC: (none) => henk

Comment 5 Morgan Leijström 2015-08-28 18:52:47 CEST
@Henk: have you set the applet to require root login?

-----

Today it was not until the third KDE logout/login it failed, i get corresponding output as Henk.


"Thankfully", as mageia servers was offline a while, i could not report it immediately, and now some hours later *in same login*, in the same terminal i issue drakconf again just in case - and now it works!!

bash-4.3$ cat /run/systemd/users/$(id -u)
# This is private data. Do not parse.                                         
NAME=morgan                                                                   
STATE=active                                                                  
RUNTIME=/run/user/10702                                                       
SERVICE=user@10702.service                                                    
SLICE=user-10702.slice                                                        
DISPLAY=c8
REALTIME=1439542090070297
MONOTONIC=23200603
SESSIONS=c8 c1
SEATS=seat0 seat0
ACTIVE_SESSIONS=c8
ONLINE_SESSIONS=c8
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0

NOTE when OK the line STATE is =active  (when not working it is =online)
Comment 6 Henk Elbers 2015-08-28 19:52:47 CEST
I took me several logout/logins and 2 or 3 reboots, but now it's working again.
And the state is "active" now.
I also lost my sound, but that's back too.

@Morgan: No, the applet just asks for my own password.

I think that the problem started today when I logged in with an USB-stick inserted. It did not come on until I took it out and inserted it again. Soon
after that I found out that things were not working properly.
Comment 7 John L. ten Wolde 2015-08-29 23:22:37 CEST
I've got the same findings as Morgan: when it works STATE=active; when it fails STATE=online.
Comment 8 John L. ten Wolde 2015-08-30 00:18:06 CEST
I was just looking into what this STATE business was all about and found this on the sd_uid_get_state (3) manpage:

  "online" (user logged in, but not active, i.e. has no session in the
  foreground),

  "active" (user logged in, and has at least one active session, i.e. one
  session in the foreground),

Well that certainly makes our results of "online" sound wrong.
Comment 9 Luc Menut 2015-08-31 21:58:08 CEST
Thanks for feedback.
yep, the wrong STATE is the issue.

Since polkit 0.113, polkit uses sd_session_is_active() to check session activity, as requested by systemd's devs.
http://lists.freedesktop.org/archives/polkit-devel/2015-July/000432.html
polkit-0.113 released
...
Changes since polkit 0.112:
...
Philip Withnall (1): 
sessionmonitor-systemd: Use sd_uid_get_state() to check session activity
https://bugs.freedesktop.org/show_bug.cgi?id=76358
http://cgit.freedesktop.org/polkit/commit/?id=a29653ffa99e0809e15aa34afcd7b2df8593871c

With our systemd (217-11.mga5) this state is sometimes wrong with STATE=online instead of STATE=active.

This is fixed upstream in systemd v221 by
logind: Save the userâs state when a session enters SESSION_ACTIVE
http://cgit.freedesktop.org/systemd/systemd/commit/?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6
https://bugs.freedesktop.org/show_bug.cgi?id=90818

see also a full analyse of this bug in Fedora bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1243319

we should backport
http://cgit.freedesktop.org/systemd/systemd/commit/?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6
in mga5 systemd in order to fix this issue.

See Also: (none) => https://bugs.freedesktop.org/show_bug.cgi?id=90818
Assignee: bugsquad => mageia
Source RPM: (none) => systemd-217-11.mga5

Comment 10 Henrik Christiansen 2015-09-16 11:46:28 CEST
I have almost the same on 1 laptop with Mageia 5 kde.
Can't run mcc from the icon and get no dialog/gui when I hit
Leave -> Shut down

If I run drakconf from konsole as user i get this:

$ drakconf
==== AUTHENTICATING FOR org.mageia.drakconf.pkexec.run ===
Authentication is required to run Mageia Control Center GUI
Authenticating as: root
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported.


State is active:
$ cat /run/systemd/users/$(id -u)
# This is private data. Do not parse.
NAME=x
STATE=active
RUNTIME=/run/user/500
SERVICE=user@500.service
SLICE=user-500.slice
DISPLAY=c1
REALTIME=1442390231969012
MONOTONIC=67279257
SESSIONS=c1
SEATS=seat0
ACTIVE_SESSIONS=c1
ONLINE_SESSIONS=c1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0

CC: (none) => hc

Comment 11 Henrik Christiansen 2015-09-16 12:20:14 CEST
Forgot to write that this is without any logouts/ins.
This happens after boot when I try to run mcc from the icon
or Leave -> Shut down
Samuel Verschelde 2015-09-16 14:53:31 CEST

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=16319

Comment 12 Florian Hubold 2015-09-17 21:01:50 CEST
(In reply to Luc Menut from comment #9)
> Thanks for feedback.
> yep, the wrong STATE is the issue.
> 
> Since polkit 0.113, polkit uses sd_session_is_active() to check session
> activity, as requested by systemd's devs.
> http://lists.freedesktop.org/archives/polkit-devel/2015-July/000432.html
> polkit-0.113 released
> ...
> With our systemd (217-11.mga5) this state is sometimes wrong with
> STATE=online instead of STATE=active.
> 
> This is fixed upstream in systemd v221 by
> logind: Save the userâs state when a session enters SESSION_ACTIVE
> http://cgit.freedesktop.org/systemd/systemd/commit/
> ?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6
> https://bugs.freedesktop.org/show_bug.cgi?id=90818
> ...
> we should backport
> http://cgit.freedesktop.org/systemd/systemd/commit/
> ?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6
> in mga5 systemd in order to fix this issue.

Luc, thanks for the thorough analysis. I'll do a test build and report back, as we have an easily reproducible test case for the issue reported in comment 0

Now we still need to figure out what's wrong for all the people that still have polkit issues in general (not caused by the polkit service not being restarted during the mga5 polkit update https://bugs.mageia.org/show_bug.cgi?id=16135 )

E.g. for Henrik above where polkit fails after a fresh boot. And dozens more people reported similar stuff in forums, reasons yet unknown. polkit service and polkit agents seem to be running fine.

Priority: Normal => High
CC: (none) => doktor5000

Comment 13 Michel AUTEM 2015-09-29 11:36:34 CEST
(In reply to John ten Wolde from comment #0)

I get the same kind of problem/bug in GNOME rather regularly but I am totally unable to reproduce it and to characterize the trigger event : after leaving the last session without any apparent trouble and opening a new session, I'm unable to launch MCC. I can do it in my session from a terminal, or connecting in an other session (as "root" or an other User ID) but it does not work in the GNOME GUI.

A serial of other troubles are concomitant, like loosing the sound in Banshee or blocking PulseAudio Volume Control.

Disconnecting/reconnecting the session does nothing, nor rebooting the system.

The problem has something to see with iBus cache corruption because it appears completely solved by manually deleting the /home/<MyId>/.cache/ibus/bus/registry file (or the whole directory) and then restarting the session.

CC: (none) => michel.autem

Comment 14 Florian Hubold 2015-10-04 15:52:12 CEST
Ok, got this also after having issues on starting display manager automatically on boot. Weird thing is, pkexec direct call works just fine, but calling our drakxtools fails (weird as they also essentially call pkexec).

[doktor5000@Mageia5]â[15:20:49]â[~] mgaapplet-config
Error executing command as another user: Not authorized

This incident has been reported.

[â]â[doktor5000@Mageia5]â[15:21:09]â[~] pkexec whoami
root

[doktor5000@Mageia5]â[15:23:06]â[~] cat /run/systemd/users/$(id -u)
# This is private data. Do not parse.
NAME=doktor5000
STATE=online
RUNTIME=/run/user/1000
SERVICE=user@1000.service
SLICE=user-1000.slice
DISPLAY=c9
REALTIME=1443903417013958
MONOTONIC=40092786
SESSIONS=c9 c1
SEATS=seat0 seat0
ACTIVE_SESSIONS=c9
ONLINE_SESSIONS=c9 c1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0 seat0


Reason here is clearly what Luc mentioned, session is considered "online" rather then "active". I've added http://cgit.freedesktop.org/systemd/systemd/commit/?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6 to a local systemd version, and will test. Probably a sane idea to push this to updates_testing for others to test.

So please try with systemd-217-11.1.mga5 if your issues still persist.

If they do, please at the very least provide a short but clear description how you start your X session, and provide the output of

cat /run/systemd/users/$(id -u)
ps -ef|grep -v grep|grep polkit
systemctl status polkit.service -a

Status: NEW => ASSIGNED
Assignee: mageia => doktor5000
Summary: MCC won't start after logging out/in to KDE session => MCC won't start after logging out/in to KDE session - session recognised by polkit as "online" vs. "active"

Comment 15 Florian Hubold 2015-10-04 15:55:04 CEST
(In reply to Henrik Christiansen from comment #10)
> I have almost the same on 1 laptop with Mageia 5 kde.

Yep, almost the same. Please first create a thread in our forums https://forums.mageia.org/en so I can take a closer look. Your issue looks pretty different as your session is active, not online. And you get a different error message:

> polkit-agent-helper-1: error response to PolicyKit daemon:
> GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Comment 16 Florian Hubold 2015-10-04 16:34:33 CEST
@Bugsquad: For reference, I tried to summarize the current 2 polkit issues we have in this forum post: https://forums.mageia.org/en/viewtopic.php?p=59728#p59728
If you see more polkit issues, please ping me on IRC or so.
Comment 17 Samuel Verschelde 2015-10-04 20:56:13 CEST
(In reply to Florian Hubold from comment #16)
> @Bugsquad: For reference, I tried to summarize the current 2 polkit issues
> we have in this forum post:
> https://forums.mageia.org/en/viewtopic.php?p=59728#p59728
> If you see more polkit issues, please ping me on IRC or so.

Ok, noted.
Comment 18 Rémi Verschelde 2015-10-05 18:31:17 CEST
I was able to reproduce the issue this morning by logging out and back into KDE. I practically never logout, only shutdown, that's why I hadn't had the issue before trying to actually reproduce it.

I installed the systemd update candidate, and now after through logout and login back into KDE, I have no issue: the session state is "active" as expected, and I can start e.g. MCC from the launcher.

So MGA5-64-OK.

Whiteboard: (none) => MGA5-64-OK

Comment 19 Florian Hubold 2015-10-05 19:23:52 CEST
(In reply to Rémi Verschelde from comment #18)
> So MGA5-64-OK.

Shall I assign this to QA then? I'd at least like to get some feedback from Colin before we validate this. I mean, this is only a one-line patch that is applied for the fix, but maybe Colin has some more systemd patches that should be applied.

Are there more bugs open against systemd for mga5 currently?
Comment 20 Florian Hubold 2015-10-07 19:44:41 CEST
Assigning to QA team for testing, if the advisory is OK/understandable I'd like to upload that to SVN. Sadly I have no clear steps to reproduce, the following has to suffice:


1. verify the state of your user session is active via "grep -i state /run/systemd/users/$(id -u)"
2. verify that you can run commands via polkit as normal user, e.g. "pkexec whoami" or "drakconf" should work after providing the password to the polkit agent dialog
3. logout from your desktop session, and login again - if the check from 1. now returns the state as online then the commands from 2. should fail
4. after installing the update the issue from 3. should be fixed, the session of the current user should always be state=active.

See comment 14 for the first validation example.



Suggested advisory:
========================
Since polkit 0.113, polkit uses sd_session_is_active() to check session
activity, as requested by systemd's developers: 
https://bugs.freedesktop.org/show_bug.cgi?id=76358
http://lists.freedesktop.org/archives/polkit-devel/2015-July/000432.html
http://cgit.freedesktop.org/polkit/commit/?id=a29653ffa99e0809e15aa34afcd7b2df8593871c


With our previous systemd version 217 this state is sometimes wrong with
STATE=online instead of STATE=active. This happens either after a user logs out,
and logs back in again to his X session, or in some cases when the display manager / X session is manually started from a terminal
In each case, it results in polkit not being able to start any program with root authorisation, and there is no workaround for this.

An explanation of the two states from sd_uid_get_state (3) manpage:

"online" (user logged in, but not active, i.e. has no session in the foreground)

"active" (user logged in, and has at least one active session, i.e. one session in the foreground)

This has been fixed by backporting a patch from systemd 221 to logind:

logind: Save the userâs state when a session enters SESSION_ACTIVE
http://cgit.freedesktop.org/systemd/systemd/commit/?id=41dfeaa194c18de49706b5cecf4e53accd12b7f6


References:

https://bugs.freedesktop.org/show_bug.cgi?id=90818
https://bugzilla.redhat.com/show_bug.cgi?id=1243319
========================

Updated packages in core/updates_testing:
========================
i586
libgudev1.0_0-217-11.1.mga5.i586
libgudev1.0-devel-217-11.1.mga5.i586
libgudev-gir1.0-217-11.1.mga5.i586
libsystemd0-217-11.1.mga5.i586
libudev1-217-11.1.mga5.i586
libudev-devel-217-11.1.mga5.i586
nss-myhostname-217-11.1.mga5.i586
python-systemd-217-11.1.mga5.i586
systemd-217-11.1.mga5.i586
systemd-devel-217-11.1.mga5.i586
systemd-units-217-11.1.mga5.i586

x86_64
lib64gudev1.0_0-217-11.1.mga5.x86_64
lib64gudev1.0-devel-217-11.1.mga5.x86_64
lib64gudev-gir1.0-217-11.1.mga5.x86_64
lib64systemd0-217-11.1.mga5.x86_64
lib64udev1-217-11.1.mga5.x86_64
lib64udev-devel-217-11.1.mga5.x86_64
nss-myhostname-217-11.1.mga5.x86_64
python-systemd-217-11.1.mga5.x86_64
systemd-217-11.1.mga5.x86_64
systemd-devel-217-11.1.mga5.x86_64
systemd-units-217-11.1.mga5.x86_64

Source RPMs: 
systemd-217-11.1.mga5.src.rpm

Assignee: doktor5000 => qa-bugs

Comment 21 Colin Guthrie 2015-10-08 10:20:02 CEST
Thanks for this Florian!
William Kenney 2015-10-08 18:46:38 CEST

CC: (none) => wilcal.int

Dave Hodgins 2015-10-09 00:49:06 CEST

CC: (none) => davidwhodgins
Whiteboard: MGA5-64-OK => MGA5-64-OK advisory

Dave Hodgins 2015-10-09 01:10:24 CEST

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Comment 22 Mageia Robot 2015-10-09 20:48:35 CEST
An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0145.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Comment 23 Xuo 2017-01-09 21:42:47 CET
Hi,

This bug is still available for me on at least 2 laptops.
I am running mageia5 x86_64 on the first one, mageia5 i686 on the second one.

It does not depend on the fact that I log in or out from a previous session. This behaviour occurs since several months but I was leaving with it (see (in french) https://www.mageialinux-online.org/forum/topic-20672+drakconf-mcc-ne-se-lance-pas-a-partir-de-son-icone-sous-xfce.php). As I've installed Mageia on another laptop, and see this bug was still there, I'd like to re-open this bug.

After the first login (after reboot), I can't run mcc from the desktop icon nor as user xuo :

/home/xuo 16 # mcc
==== AUTHENTICATING FOR org.mageia.drakconf.pkexec.run ===
Authentication is required to run Mageia Control Center GUI
Authenticating as: root
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported.

cat /run/systemd/users/500
# This is private data. Do not parse.
NAME=xuo
STATE=active
RUNTIME=/run/user/500
SERVICE=user@500.service
SLICE=user-500.slice
DISPLAY=c2
REALTIME=1483992687380753
MONOTONIC=89383081
SESSIONS=c2
SEATS=seat0
ACTIVE_SESSIONS=c2
ONLINE_SESSIONS=c2
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0


Any idea ?

Regards.

Xuo.

Priority: High => Normal
Status: RESOLVED => REOPENED
CC: (none) => xuoy
Resolution: FIXED => (none)
Severity: normal => minor

Nicolas Lécureuil 2017-01-09 21:59:42 CET

Keywords: validated_update => (none)
CC: (none) => mageia

Comment 24 Rémi Verschelde 2017-01-10 09:42:54 CET
Thanks for the report, but please open an new issue that would reference this one. This bug report was used by the QA team to validate an update, and this cannot be reverted, so it should stayed as RESOLVED FIXED.

Keywords: (none) => validated_update
Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Comment 25 Michel AUTEM 2019-08-26 13:16:21 CEST
I would like to re-open this ticket, which was *never* resolved *at all*, at least for five years and three versions of Mageia : I get still exactly the same symptoms as Xuo in Mageia 7.1 !

This bug occurs *only* when I'm connected under my logId. Everything works fine in any other account, "root" but also any *new* account I create.

But suppressing *my* account and re-creating it (keeping /home ..) has no effect : impossible to launch the MCC, and any appli needing "root" privileges.

----------------------------------------------------------------
[michel@localhost ~]$ grep -i state /run/systemd/users/$(id -u)
STATE=active
[michel@localhost ~]$ pkexec whoami
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/usr/bin/whoami' as the super user
Authenticating as: root
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ====
Error executing command as another user: Not authorized

This incident has been reported.
[michel@localhost ~]$
-----------------------------------------------------------------

Resolution: FIXED => (none)
Status: RESOLVED => UNCONFIRMED
Ever confirmed: 1 => 0

Comment 26 Dave Hodgins 2019-08-27 02:33:25 CEST
(In reply to Michel AUTEM from comment #25)
> I would like to re-open this ticket, which was *never* resolved *at all*, at
> least for five years and three versions of Mageia : I get still exactly the
> same symptoms as Xuo in Mageia 7.1 !
> 
> This bug occurs *only* when I'm connected under my logId. Everything works
> fine in any other account, "root" but also any *new* account I create.
> 
> But suppressing *my* account and re-creating it (keeping /home ..) has no
> effect : impossible to launch the MCC, and any appli needing "root"
> privileges.

Most likely cause is that you've previously used the su command (rather
then su --login which can be abbreviated as just "su -"), and then run
anything that updates files in /home leaving them owned by root. If that
is the case, try running the following
su -
chown -Rc michel:michel /home/michel
exit

Replace all three occurrances of michel in the chown command with the user
that is used on that system, if it isn't michel.

Then see if the "pkexec whomai" works.
Comment 27 Michel AUTEM 2019-08-27 10:11:17 CEST
Hi Dave,
Your logic bears common sense : "something" seemed to have been changed or even corrupted, somewhere in my /home, that was like I had lost some privileges somewhere . But I don't see how that could be an effect of acting as "root" or any other logId .. I had already suppressed (renamed..) my .cache directory and that did *nothing*. Then I applied your command and .. that did nothing ..

But good news now : looking again at the errors messages I got when launching MCC in a console, it came to Me in a flash : I opened "Session & Startup" in my Xfce tools, went in the "Application Automatic Startup" index, and there ... the "Policykit Authentication Agent" was *UNCHECKED* !! I re-checked it, rebooted the system, and now everything works again like a charm.

Why ? How ? When ? Who ? Don't ask Me, I **NEVER** went there before ! Maybe that occurred when I installed/de-installed some component, and something could be extracted from the system logs, but I'm not clever enough in Linux.

Best regards.
Comment 28 David Walser 2019-08-29 13:06:42 CEST
You can't reopen this bug.

Resolution: (none) => FIXED
Status: UNCONFIRMED => RESOLVED

Comment 29 Michel AUTEM 2019-08-29 14:17:45 CEST
Hi David,

Not a problem, I just killed it .. ;-)

Note You need to log in before you can comment on or make changes to this bug.