Feature: Systemd timers

Create, inspect and (to some extent) modify systemd timers.

Notes

• Interesting attributes for running commands: workdir, env variables, username, private tmp (+namespace), wants
• Other interesting attributes: Acuracy, persistency, wakes system
• Interesting man pages: systemd.service systemd.timer systemd.unit

Stories

Phillip

Wants to run custom daily cleanups every day. It doesn't really matter if it's skipped one day. But he wants to monitor when it was run last time. His cleanups require running database.

Gregory

Wants to generate summaries: every hour, day, week, month, year. He does it by running custom commands. His commands work a lot with /tmp and he doesn't want to pollute it. It's also crucial that his commands are run even if his server is not running at specified time.

Jan

Wants to run existing unit one hour after system start.

Bruce

Wants to monitor when dnf generates cache

Workflows

Phillip:

• Opens services -> timers
• Clicks on create button
• Creates his timer with custom commands
• He also select database server in wants field
• Then he sees next time when it will be run which confirms he's done it right
• He also might want to change cleanup frequency

Gregory:

• Creates his timer
• He specifies private tmp
• Because he wants to share tmps between all his summary generators he specifies namespace

Jan:

• Creates timer

Bruce:

• Looks at timer summary page

Implementation Notes and Technical Limitations

• Timers running commands will be implemented using one .service unit and one .timer unit
• .service unit created by cockpit will have X-COCKPIT-TIMER attribute set to true
• We are limited by systemd capabilities
• We will need to create D-Bus API for creating and modifying timers.

D-Bus API

Method to create unit - here you specify name, and key-val pairs of config info. maybe this:

        sa{sa{ss}}
        |  |  ||
      Name |  |Value
 Section name |
             Key

Method to modify unit:

sa{sa{ss}}

Types are same as in previous. Empty value strings mean: delete this parameter.

Question: What to implement this in? Is vala OK?

This service will be D-Bus activated and will exit after first method call or timeout (1 minute?).

Bus name: How about org.cockpit-project.SystemdUnit1

Wireframes

I need something to select multiple item from (long) list. Patternfly doesn't support this. It's required for selecting units which have to be running before timer is run.

First design:

Quick implementation:

Timer overview:

Creation dialog:

Implementation steps

1. Now I'm working on creation dialog (GUI only)
2. Next step is designing and implementing D-Bus API
3. Implement action on create button press
4. Next is edit button -- dialog and action.
   • This can reuse previous steps.
5. Then page which shows up when you click on timer
   • This page should show: .timer journal, .service journal and information which you input into creation dialog

Prior art

Links to screenshots or documentation of other places this problem has been solved.

• None?

Feedback

Please give feedback on the above! This is the place where those not working on the feature can provide insight, questions, limitations, notes etc.

• I think creating custom daemons is a bit of a workaround, it would be better to extend systemd to generate unit files as necessary. (Dominik Perpeet)
• Patternfly does support selecting multiple items from a list, see https://www.patternfly.org/widgets/#bootstrap-select (Dominik Perpeet)
• I don't think we've used vala in Cockpit yet. Our active set of languages consists of C, JavaScript, CSS/HTML and Python (see wiki on coding guidelines). If you have a good reason to pick something else, that is fine. (Dominik Perpeet)
• The user stories mostly center on creating timers, except for Bruce, who looks at timer summary page. Would it be worth adding a story about timer modification? What's the behavior if the user changes a running timer? Which modifications require special care? (Dominik Perpeet)
• Will service units with X-COCKPIT-TIMER attribute be deleted when they aren't needed anymore? What about possible user modifications? Do they matter, does it happen? (Dominik Perpeet)
• You said "We are limited by systemd capabilities" - which limits are you referring to? (Dominik Perpeet)
• It is good to sort out the UI / workflows first, this should identify early if something's wrong or missing in the design. (Dominik Perpeet)
• The stories are a bit brief. Who are Phillip, Jan, Gregory and Bruce? Why are they carrying out these tasks and what is their end goal? How does this part fit in to a bigger story? (Andreas Nilsson)
• Since the focus on Cockpit is on servers, does it make sense to have WakeSystem in there, or is that more of a laptop thing? (Andreas Nilsson)