RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1418886 - Trying to start, stop, restart services with systemd fails and returns dbus timeout (g-dbus-error-quark, 20)
Summary: Trying to start, stop, restart services with systemd fails and returns dbus t...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.3
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 74systemd
TreeView+ depends on / blocked
 
Reported: 2017-02-03 00:39 UTC by Joe Wright
Modified: 2024-12-20 18:42 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-15 10:10:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Joe Wright 2017-02-03 00:39:49 UTC 
Description of problem:
Trying to start, stop, restart services with systemd fails and emits errors like:
Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.PolicyKit1 timed out (g-dbus-error-quark, 20)

Version-Release number of selected component (if applicable):
- polkit-0.112-9.el7.x86_64
- systemd-219-30.el7_3.6.x86_64
- dbus-1.6.12-17.el7.x86_64
- kernel-3.10.0-514.6.1.el7.x86_64

How reproducible:
- unsure. Unable to reproduce in-house

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
- Permissions on tmp shadow and passwd are correct
- rpm verification ok

Based on the following logs it seems that the issue could be with systemd and not specific to polkit :

Jan 25 17:19:28 localhost systemd-logind: Failed to fully start up daemon: Connection timed out
Jan 25 17:19:28 localhost dbus[908]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Jan 25 17:19:28 localhost dbus-daemon: dbus[908]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Jan 25 17:19:28 localhost systemd: systemd-logind.service: main process exited, code=exited, status=1/FAILURE
Jan 25 17:19:28 localhost systemd: Failed to start Login Service.
Jan 25 17:19:28 localhost systemd: Unit systemd-logind.service entered failed state.
Jan 25 17:19:28 localhost systemd: systemd-logind.service failed.
Jan 25 17:19:28 localhost systemd: systemd-logind.service has no holdoff time, scheduling restart.
Jan 25 17:19:28 localhost systemd: Starting Login Service...

The line "Jan 25 17:19:28 localhost dbus[908]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out" seems to be pointing to the issue.

On checking for issues reported for upstream, I could see systemd being responsible for the issue. Following are the upstream reported issues:

https://github.com/systemd/systemd/issues/2019
https://bugs.freedesktop.org/show_bug.cgi?id=93066
https://github.com/systemd/systemd/issues/2925
Comment 3 Lukáš Nykrýn 2017-02-06 10:53:21 UTC 
I don't think that logind would block systemctl start/....
This seems to be a bigger problem:
Jan 25 17:19:28 localhost dbus-daemon: dbus[908]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Comment 7 Daniel Ouimet 2017-12-19 19:06:30 UTC 
I have the exact same problem with a server I just updated.
My version number are different (except for dbus is the same):
polkit-0.112-12.el7_3.x86_64
systemd-219-42.el7_4.4.x86_64
kernel-3.10.0-693.11.1.el7.x86_64

The problem seems to be polkit that can't start org.freedesktop.PolicyKit1
Here is a part of the start of polkit:
polkitd[139162]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
systemd[1]: polkit.service start operation timed out. Terminating.
Failed to start Authorization Manager.

dbus and other services are not starting for this reason. I googled the problem and didn't see anything.

I am not using SELinux, so this is not the problem.
And I reinstall polkit just in case: yum reinstall polkit
And reinstall dbus too, just in case!
I checked that all the rules in /etc/polkit-1/ are exactly the same with exact same permission as 1 year ago. Done!

There is a bug in the way that polkit is started (is it in polkit? dbus? systemd?)

A strace of the start of polkit seems normal until at the end it loops on:
poll([{fd=5, events=POLLIN}, {fd=8, events=POLLIN}], 2, -1) = 1 ([{fd=5, revents=POLLIN}])
read(5, "\1\0\0\0\0\0\0\0", 16) = 8
with sometimes this line appears:
futex(0x560d2fca1d50, FUTEX_WAKE_PRIVATE, 1) = 1

So there is a real bug in the updates because it was working perfectly before the update.
Comment 8 Daniel Ouimet 2017-12-22 14:42:12 UTC 
Problem solved!
I don't know if your problem was the same, but mine was that setroubleshoot user was absent from the /etc/passwd

setroubleshoot-server was complaining it could not be updated because the setroubleshoot group was there but not the user. So I removed the group, reinstall setroubleshoot with an update. After I restart by hand (with systemctl) all other failed deamon beginning with polkit, and voila!

Hope this helps you find your problem.

Daniel
Comment 9 nk5 2018-07-09 02:54:05 UTC 
Anyone else pulling their hair out with this issue - run a quick pwck and see if anything is amiss. Due to a fat-finger search and replace, I managed to remove the home directory field for systemd-network and polkitd, making both accounts invalid and systemd/polkitd very upset.
Note You need to log in before you can comment on or make changes to this bug.