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 runs web service which involves uploading files to server.

He wants to run custom daily cleanups every day (delete files of non-premium users). 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 to check if user has premium account.

Gregory runs intranet application server which monitors employees' productivity.

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)
  • I agree. I sent email to systemd-devel mailing list.
• 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)
  • Reasons for using vala are 1. It's temporary workaround 2. It generates C(GObject) so it's code generator. 3. It's really easy to create D-Bus services in it (you just create class annotate it and you're done)
• 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)
  • This part is handled by systemd.
  • I don't think that modifications require special case
• 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)
  • That's why in my proposed D-Bus API I only modify or add values not overwrite everything. So user modifications which cockpit doesn't know about are leaved intact. Modifications which cockpit understands are show in modification GUI.
  • Deletion when not needed: I think we should show prompt: "Do you want to delete attached service unit?"
  • X-COCKPIT-TIMER is focused on what GUI we should show on edit. Run command OR start unit?
• You said "We are limited by systemd capabilities" - which limits are you referring to? (Dominik Perpeet)
  • We cannot provide what systemd cannot. For example: Persistent option only applies to Wallclock timers.
• 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)
  • I agree that it isn't really necessary for servers. Maybe cockpit on RaspberryPI 2?