temporarily override one of two complementary timers

Question

In order to toggle light and dark color schemes, I've set up two units that run a script that creates a symbolic link to my termite configuration file, when triggered by their respective timers. The linked file contains the appropriate light or dark scheme, and then when termite receives SIGUSR1, it reloads its configuration. All good.

$ systemctl --user list-timers
NEXT                         LEFT          LAST                         PASSED  UNIT             ACTIVATES
Mon 2018-11-05 14:20:00 CET  9min left     Mon 2018-11-05 14:10:13 CET  1ms ago brightside.timer brightside.service
Mon 2018-11-05 16:00:00 CET  1h 49min left n/a                          n/a     darkside.timer   darkside.service

$ cat ~/.config/systemd/user/brightside.timer
[Unit]
Description=Ensure a bright colorscheme every ten minutes during the day.

[Timer]
OnCalendar=*-*-* 09..15:0/10

[Install]
WantedBy=timers.target

So brightside.service links termite_light.conf to ${XDG_CONFIG_HOME}/termite/config every 10 minutes during the day. Then, darkside.timer takes over:

[Timer]
OnCalendar=*-*-* 16..23:0/10
OnCalendar=*-*-* 00..08:0/10

Now I'd like to override either or both of the timers by creating or removing symbolic links to either ~/.config/systemd/user/{dark,bright}side.d/override.conf using a shell script. Ultimately I want to have a programmable timer setup like on an electric socket timer. (But with the advantage of changing the seasonal daytime length). The idea here is to provide a four-way toggle:

• bright [manual]
• bright [automatic]
• dark [manual]
• dark [automatic]

If I set dark [automatic] mode during daytime, the script first sets the dark scheme. Then it should temporarily override brightside.timer or stop the timer so that we're not switching back immediately. But how do I make it so that by the time darkside.timer ends, brightside.d/override.conf got removed, or brightside.timer is started again?

I previously used AssertPathExists and empty files in /tmp to override the timer. Maybe that's still the best solution, because I'd probably be reloading the daemon to incorporate the override.conf, wouldn't I?

Answer 1

I guess one option would be to introduce two more timers (and services) that would fire once a day at the switching hours only (9am and 4pm) and have those services remove any overrides and re-enable timers as needed to remove a manual setting and return to an automatic one.

But I really think you're over-engineering this to some extent... While it's laudable that you're managing to implement this all without a single shell script and you're making great use of systemd features such as the very flexible calendar specifications of timer units and the convenience of override files, I think encoding the state of the system (dark vs. bright, manual vs. automatic) in systemd doesn't really simplify your overall solution.

As an exercise, try to imagine if your combinations were much larger. For instance, what if you had not only two color schemes per day, but three? Or if you had four different "bright" colorschemes, one for each season? Or if you wanted to adjust times for the switch based on sunrise/sunset times?

It seems to me that having a single systemd timer + service to switch colorschemes would be more appropriate, having that service invoke a script (shell, python, etc.) that would pick colorscheme, taking into account the current time but also manage existing overrides (using state files somewhere in /run perhaps.)

Such a system would be simpler overall and much more extensible than you can build with systemd units alone.