Bug 971392

Summary:	systemd update breaks polkit-kde-auth
Product:	[Fedora] Fedora	Reporter:	Jiri Eischmann <eischmann>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	19	CC:	awilliam, harald, johannbg, jreznik, kparal, lnykryn, msekleta, notting, nphilipp, plautrba, robatino, systemd-maint, vpavlin, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:	RejectedBlocker
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-06-20 08:36:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jiri Eischmann 2013-06-06 12:04:48 UTC

Description of problem:
system-config-users cannot gain root rights and because of that, it doesn't start when you start it from the KDE menu.


How reproducible:

Just search for "Users and groups" in the KDE menu and execute it.

Actual results:
The config tool doesn't start. If you run it in a terminal, it says it can't run without root rights and asks for the root password.

Expected results:
The tool should ask polkit for root rights and the user should be prompted to type a root password.

Additional info:
I'm proposing this as a F19 Finale blocker bug because it meets the criteria "All applications listed under the Applications menu or category must start successfully".

Comment 1 Jaroslav Reznik 2013-06-06 12:26:30 UTC

I can't reproduce it on my F19 installation and it looks more like Polkit issue. Are polkitd and auth agent running?

ps -A | grep polkit

Comment 2 Jiri Eischmann 2013-06-06 12:30:51 UTC

Yes, it seems like a polkit-kde issue because other things don't work either. It was TC1 after updates. Now, I'm reinstalling the machine to make sure it occurs in TC1 without updates, too.

Comment 3 Jiri Eischmann 2013-06-06 13:33:07 UTC

OK, we narrowed it down to systemd. It works with TC1 without updates and systemd 204.3, but it doesn't work with systemd 204.4 from updates-testing. polkit-kde-auth doesn't run any more for some reason.

It's not also specific to system-config-users, it affects other KDE components that require polkit, too (you can't logout, reboot,... from the KDE menu).

Comment 4 Kamil Páral 2013-06-10 14:50:09 UTC

Unfortunately I can't reproduce with TC2 x86_64 DVD. Initially there's systemd 204-3. I updated to 204-6, and then downgraded to 204-4. All with reboots. All of them worked correctly, polkit-kde-auth was running every time.

I have no idea where the difference is, because initially I worked with Jiri on this report and his findings were real.

Comment 5 Jiri Eischmann 2013-06-10 18:19:51 UTC

The bug might be related to localization. I can reproduce it every time with Czech localization, but I couldn't reproduce it with the default English one. Will investigate it a bit more tomorrow.

Comment 6 Kamil Páral 2013-06-10 18:53:24 UTC

I repeated my approach from comment 4 with Czech localization, same results - still can't reproduce.

Comment 7 Adam Williamson 2013-06-10 18:57:04 UTC

Discussed at 2013-06-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-10/f19final-blocker-review-4.2013-06-10-16.01.log.txt . For now this is rejected as a blocker as no-one else has been able to reproduce it. Please re-propose as a blocker if you can pinpoint the setup that causes this bug to occur, and it seems common enough to be worth blocker status.

Comment 8 Jiri Eischmann 2013-06-11 10:15:08 UTC

Seems like a raise condition. We've tried it many times on several computers and we cannot find any pattern. Even I can't preproduce it every time, now.

Comment 9 Lennart Poettering 2013-06-19 13:52:40 UTC

If you guys want this fixed I fear you need to track this down on your own, as I am not running KDE.

Comment 10 Kamil Páral 2013-06-20 08:36:23 UTC

After talking to Jiri, we decided to close this bug. We can't reproduce it anymore. When someone sees this problem again, feel free to reopen, thanks.