Bug 972479 - systemctl status takes about 4 minutes to complete
Summary: systemctl status takes about 4 minutes to complete
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 19
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-09 17:12 UTC by Heldwin
Modified: 2013-12-08 11:45 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-08 11:45:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Heldwin 2013-06-09 17:12:04 UTC
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):
systemd-204-6.fc19.x86_64
systemd-python-204-6.fc19.x86_64
systemd-libs-204-6.fc19.x86_64
systemd-libs-204-6.fc19.i686
systemd-sysv-204-6.fc19.x86_64


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 19:18:28 UTC
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 20:50:29 UTC
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 11:45:47 UTC
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.