Bug 1084920 - RFE: systemctl: allow listing of past elapsations of timer units
Summary: RFE: systemctl: allow listing of past elapsations of timer units
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-07 09:20 UTC by Jóhann B. Guðmundsson
Modified: 2019-08-05 20:30 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-05 20:30:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jóhann B. Guðmundsson 2014-04-07 09:20:54 UTC
Description of problem:

So here's the thing currently systemd list-timers covers only the short administrative use case of debugging failed time triggers on systems so we will need to extend it to cover further debugging/inspection of a timer units by running something like "systemctl list-timer my-time-trigger.timer" and or  "systemctl list-timer my-time-trigger.service" ( or all types units time triggers can be bound to ) which outputs from beginning of time ( as far back as the journal has it in it's logs ) and provides the following in it's output

When the timer units ran
If the time trigger ran successfully or failed
If the associated type service units ran successfully or failed
Who ran it ( User= in [Service] section  )
What got executed ( ExecStart= in [Service] section ) 

The above in conjunction with the overview list-timers provides,should cover all administrative use cases for debugging/inspecting systemd's time triggers

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Zbigniew Jędrzejewski-Szmek 2014-04-07 13:47:17 UTC
You mean something like 'journalctl -u my-time-trigger.timer -u my-time-trigger.service'? Or something different?

Comment 2 Jóhann B. Guðmundsson 2014-04-07 17:34:52 UTC
Something different more in terms of historic overview of the time trigger unit(s) which show when it ran, what it ran and who it got run as and if it was successful running it or not as in the time trigger never got triggered or the service unit tied to the timer unit never ran or if it ran if the execstart section failed which you then would proceed into using journalctl -u to further inspect why the time trigger job failed

Comment 3 Zbigniew Jędrzejewski-Szmek 2014-04-07 18:04:41 UTC
I don't think we want to keep more information in memory. Everything you list should be stored in the journal. So we should a) make sure that the logs are adequate, and b) consider adding a switch to show everything about a trigger and the trigerees.

Comment 4 Jóhann B. Guðmundsson 2014-04-07 22:17:38 UTC
Right this info needs to be fetch from the journal

Comment 5 Zbigniew Jędrzejewski-Szmek 2019-08-05 20:30:24 UTC
journalctl -u does a good-enough job.

E.g.:
$ journalctl -u dnf-makecache.timer
-- Logs begin at Thu 2017-05-04 00:52:03 CEST, end at Mon 2019-08-05 22:28:05 CEST. --
Jul 02 19:25:37 spora systemd[1]: Started dnf makecache timer.
-- Reboot --
Mar 11 02:50:12 spora systemd[1]: Started dnf makecache timer.
Mar 15 17:29:52 spora systemd[1]: Stopped dnf makecache --timer.
Mar 15 17:29:52 spora systemd[1]: Stopping dnf makecache --timer.
Mar 15 17:29:52 spora systemd[1]: Started dnf makecache --timer.
Mar 25 16:14:23 spora systemd[1]: Stopped dnf makecache --timer.
Mar 25 16:14:23 spora systemd[1]: Stopping dnf makecache --timer.
Mar 25 16:14:23 spora systemd[1]: Started dnf makecache --timer.
-- Reboot --
Apr 09 10:38:21 spora systemd[1]: Started dnf makecache --timer.
Apr 24 20:14:47 spora systemd[1]: Stopped dnf makecache --timer.
...


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