cockpit
cockpit copied to clipboard
cockpit-project
services: No ability to edit timers
This came up in the usability testing. There is apparently no way to edit a timer. Either if you did something wrong during the creation of it, or if you want to change the time it runs. Also we might want to enable users to delete them.
The details page also doesn't show timer specific things like when it will trigger next.
Altogether, a complete editing experience should include:
- Edit timers (most likely implemented with a prefill of the new timer with the previous settings, then when saving: remove the old one and create the new one with the sa,e filename)
- Delete timers (probably for Cockpit-created / manually created timers)
- Show manually added (probably Cockpit-added timers, really) at the top of the list, so they're easier to see (versus the system-installed timers)
I wonder if it's possible to add a custom field to the [Timer] section, such as CockpitEditable=true, which would allow us to find out which ones were custom made by Cockpit and are allowed to be edited in Cockpit. (I'm not sure if this would be fine with systemd, but I imagine it would be? We'd need to make sure.)
We probably don't want to edit system timers, right? Or if we "edit" system ones, we probably would want to create a custom timer based on the settings in the system-installed one and disable the original when enabling our custom one.
possible to add a custom field to the
[Timer]section, such asCockpitEditable=true.
Yes, that's possible with the common X- prefix convention, i.e. X-Cockpit-Editable.
Oh, that's really neat, but people might already have custom timers. My WiP PR for deleting timers checks for timers in /etc/systemd/system so we don't edit system timers.
Another issue is that timers currently overwrite existing timers, so ideally it would not allow that too.
Another issue is that timers currently overwrite existing timers, so ideally it would not allow that too.
Yeah, we should definitely check for that. We could use a force overwrite pattern of sorts (perhaps like the account's force weak password in the account password modal) where the main button is disabled (to prevent accidental misclicks) and a secondary button shows up to force overwrite it. I suppose we'd want to have an error message of sorts show up, like an inline alert at the top of the modal showing that the timer's filename already exists.
@garrett, @jelly, @martinpitt Another feature that would be a great add (maybe there is already a way im not seeing) is the ability for the timer to repeat at a certain frequency. more specifically every x seconds, minutes, hours from creation. something like
thoughts?
should I finish pounding this out and submit a PR or is there other larger changes in progress?
@garrett, @jelly, @martinpitt Another feature that would be a great add (maybe there is already a way im not seeing) is the ability for the timer to repeat at a certain frequency. more specifically every x seconds, minutes, hours from creation. something like
thoughts?
I wonder how is this different from adding Minutely next to `Hourly. Currently hourly with 5 minutes generates:
[jelle@t14s][~]%systemd-analyze calendar '*-*-* *:5' --iterations=5
Original form: *-*-* *:5
Normalized form: *-*-* *:05:00
Next elapse: Tue 2022-07-19 18:05:00 CEST
(in UTC): Tue 2022-07-19 16:05:00 UTC
From now: 59min left
Iter. #2: Tue 2022-07-19 19:05:00 CEST
(in UTC): Tue 2022-07-19 17:05:00 UTC
From now: 1h 59min left
Iter. #3: Tue 2022-07-19 20:05:00 CEST
(in UTC): Tue 2022-07-19 18:05:00 UTC
From now: 2h 59min left
Iter. #4: Tue 2022-07-19 21:05:00 CEST
(in UTC): Tue 2022-07-19 19:05:00 UTC
From now: 3h 59min left
Iter. #5: Tue 2022-07-19 22:05:00 CEST
(in UTC): Tue 2022-07-19 20:05:00 UTC
From now: 4h 59min left
So minutely could generate:
[jelle@t14s][~]%systemd-analyze calendar '*-*-* *:*:5' --iterations=5
Original form: *-*-* *:*:5
Normalized form: *-*-* *:*:05
Next elapse: Tue 2022-07-19 17:09:05 CEST
(in UTC): Tue 2022-07-19 15:09:05 UTC
From now: 59s left
Iter. #2: Tue 2022-07-19 17:10:05 CEST
(in UTC): Tue 2022-07-19 15:10:05 UTC
From now: 1min 59s left
Iter. #3: Tue 2022-07-19 17:11:05 CEST
(in UTC): Tue 2022-07-19 15:11:05 UTC
From now: 2min 59s left
Iter. #4: Tue 2022-07-19 17:12:05 CEST
(in UTC): Tue 2022-07-19 15:12:05 UTC
From now: 3min 59s left
Iter. #5: Tue 2022-07-19 17:13:05 CEST
(in UTC): Tue 2022-07-19 15:13:05 UTC
From now: 4min 59s left
should I finish pounding this out and submit a PR or is there other larger changes in progress?
Afaik there are currently no changes being made to how the timers work.
@jelly This would work for my use case. Main difference between what I suggested and yours is mine wouldn't use OnCalendar but rather OnUnitActiveSec. but maybe that should be a different trigger option?
@jelly This would work for my use case. Main difference between what I suggested and yours is mine wouldn't use OnCalendar but rather OnUnitActiveSec. but maybe that should be a different trigger option?
OnUnitActiveSec would be something different, we already have OnBootSec which is the After system boot option. We could add OnUnitActiveSec, not sure how we would label the checkbox option.
What would happen after a reboot if OnUnitActiveSec is used? Does it basically equate to being the same as OnBootSec in that scenario? Or does the timer go away?
What's the expected use? Do this every X time units from now... on current boot only? or for every X time units "forever", starting from now?
It's explained in systemd.timer https://man.archlinux.org/man/systemd.timer.5#OPTIONS
It's explained in systemd.timer https://man.archlinux.org/man/systemd.timer.5#OPTIONS
I don't see any answers to the questions I asked on the page.
I want to know what people expect (such as @dphaas2004) and if it is still active after a boot. And if it is active after a boot, is it still relative to the time it was set or relative to boot time. The page doesn't answer these questions.
@garrett my expected behavior is that it happens at some regular frequency. Most typically for me its every minute or every 5 minutes. The specific start time of that service is irrelevant to my use case. It is expected to be persistent and continue after a reboot. In my case I need it reoccurring. isn't OnBootSec a single firing of the timer? Also when I tested OnBootSec it didnt launch automatically as I would have expected either. this may be related to #1 below.
Side notes:
- There is no options to make a timer persistent either. may want to look at adding that
- I implemented the minutely option as suggested but that doesnt really do much as it only allows for one minute intervals starting at a specific second. Does not allow for every 5 minutes. This can be done via hourly and selecting every five minute intervals but is tedious versus
OnCalendar=*:0/5orOnUnitActiveSec=5min
I was thinking just having a custom option for on calendar and then using systemd-analyze calendar to validate the entry prior to savings? Which brings me to another point. Should the timer_unit.OnCalendar or timer_unit.boot_time be validated using this method?
Editing should be an item in the kebab menu (probably with a separator, so it's Restart, Stop, Separator, Edit, and the rest) and it should bring up a modal similar to the create, but titled "Editing timer: timername" and have the values prefilled with the existing settings.