4 ms·
systemd could just support the Timer section in unit files. You could then still start the unit file manually.
by twic 3y ago
systemd could just support the Timer section in unit files. You could then still start the unit file manually.
- its-summertime 3y agoyou can run the unit and run the timer, if you start the combined unit, then should it run it as a service or as a timer? and then you can have multiple timer files for a single service too
- twic 3y agoIt would run as a service. You don't 'systemctl start' a timer as things stand now, so it's perfectly clear what that should do. If you want to have a separate timer unit, or several of them, fine. But you shouldn't have to.
- chasil 3y agoBy that logic, why not bring more types of entries into the service file? Path units for inotify triggers, mount units for NFS automounts active only when the service is running, socket units that register network triggers, all of these might have some use. It might seem cumbersome, but I do agree that configuring complex activity sometimes means many unit files. Timer units would be a clear example.
- twic 3y ago> sometimes You have identified the key point, thank you. Sometimes, things are complicated enough that you want to break configuration up into multiple units. But not always. At the moment, systemd forces you to always break it up, even when that does more harm than good.