Bug 972479 - systemctl status takes about 4 minutes to complete
systemctl status takes about 4 minutes to complete
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-06-09 13:12 EDT by Heldwin
Modified: 2013-12-08 06:45 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-08 06:45:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Heldwin 2013-06-09 13:12:04 EDT
Description of problem:

Since an update, systemctl status takes a long time to complete and to give me the hand on the terminal.

For the same service, if I do it again after I waited the 4 minutes, it completes fast. But does it again for an other one.

Version-Release number of selected component (if applicable):

Actual results:
systemctl status xxx hangs for about 4 minutes

Expected results:
that systemctl status xxx lists the status as before, with no waiting

Additional infos:
Is that can help, I got this message, after I tried to reinstall systemd:
[/usr/lib/systemd/system/auditd.service:17] Unknown lvalue 'RefuseManualStop' in section 'Service'
Comment 1 Heldwin 2013-06-09 15:18:28 EDT
I had a bunch of files in /var/log/journal/{random_name}, that could have been the cause of this wait time. 46 files of about 64 MB in size.

I have deleted them, and now there is no waiting, but it is maybe temporary.

Didn't change the way system would store the log (always have been default).
Comment 2 Zbigniew Jędrzejewski-Szmek 2013-06-09 16:50:29 EDT
systemctl currently is not very smart about showing logs. I'm not sure what exactly is in the released version in FC19, but git HEAD now shows logs for the unit from the current boot. In addition, caching of the location in the files was disabled before 204, which is probably the reason of the slowness that you're observing. I've recently sent a patch which restores the cache, it hasn't been reviewed yet, but it should ameliorate the problem once it's in.

Ideally, in 'status' we would only show logs from the last start/restart/state-change of the unit or something like that. Not too complicated, but requires someone to think of the right conditions to derive the cutoff.
Comment 3 Zbigniew Jędrzejewski-Szmek 2013-12-08 06:45:47 EST
This should be mostly fixed now. systemctl status show messages from the last boot only, location caching is enabled. Please reopen if you observe such slowness again.

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