5 ms·
'Make everything simple as it can be but no simpler'. To me your ask violates this. Timers augment the variety of existing service types, so your idea just doe
by rektide 4y ago
'Make everything simple as it can be but no simpler'. To me your ask violates this.
Timers augment the variety of existing service types, so your idea just doesnt work straight up, unless we severely limit the flexibility of what timers can be via the 'periodic' type. Or we make 'periodic-oneshot' 'periodic-serice' et cetera, which feels absurd.
Perhaps we could leave Service= alone & just shoehorn each systemd.timer option into system.service. But then we need some way to view the timer statuses & logs, which we can easily review and handle by having a separate unit. 'list-timers' is ok & might still work but we cant filter and log as well if everything is jammed together. We also cant just disable a timer temporarily, & go manage the service manually for a bit, if somethings going sideways & we need to step in; the two are now one in your world.
And what if you want multiple timers, with different configurations between them (maybe one long running one with WakeSystem= and a shorter one without?). We eliniate a lot of creative ability by glomming stuff together.
I dont like this idea. I think it's a misservice to jam everything together. Systemd has similar patterns of representing different pars in different places that I think has served it well. It's an even more trivial case that is more supportable by this idea you've floated, but there is a systemd.mount and systemd.automoumt. It's just good, as an operator, having clear boundaries between these units, and has always made it clearer to me what aspect Im operating on, and enabled healthier patterns of system growth.
- traverseda 4y ago>And what if you want multiple timers, with different configurations between them (maybe one long running one with WakeSystem= and a shorter one without?). Well, that's where you can write a regular timer or just add a dependency to your timer-service. But also you're sort of getting to the territory of inventing your own scripting language on top of systemd at that point, if your needs are that complex just write a script.
- rektide 4y agoThis feels quite dismissive to me. I dont see the appeal of any of these three options, given how well systemd.timers solve all of this today & how nicely they compose. The whole point is to not need to keep running into a bunch of artisinal handcrafted did-it-myself shell scripts every time come to a system. Being able to compose timers that trigger units enables this nicely with a lot of flexibility. Managing them separately is powerful & makes sense.
- deleted 4y ago[deleted]
- ilyt 4y ago> And what if you want multiple timers, with different configurations between them (maybe one long running one with WakeSystem= and a shorter one without?). We eliniate a lot of creative ability by glomming stuff together. It's not either-or situation. The .service could just have [Timer] block Then you could just put all in one file, or still have option of putting timer somewhere else.
- dale_glass 4y agoThen it'd be annoying if you have to stop a timer temporarily
- rfmoz 4y agoIt’s odd, but actually you can not restart an active unit with a timer
- traverseda 4y ago>We also cant just disable a timer temporarily Sure you can, comment that line out of the service file. It is ultimately just a text file that you can edit.
- rektide 4y agoAgain, inventing arbitrary hacks totally on your own that none of the builtin tools will know about or help you do. This seems obviously worse than having a seperate services actuated by separate timers.