Well, I also came with another idea. of course if you do not want to have two different ways to do one thing it is a stopper, but I will tell about it for completeness as it may or may not be easier to implement. Instead of creating a timer unit on service file installation or something, you could have service and similar sections in the timer unit, so the other way around. then, if service name is not explicitly set in the unit and the service file with appropriate name does not exist, it could just create it using information found in the timer unit file, if such information can be found. The service file will be generated in /run/systemd/system for example and it will work normally. So, except the reason about not wanting to have two different ways of doing one thing, it does not have other problems of the approach mentioned first unless you also have another reasons not to generate service units this way.
W dniu 08.07.2016 o 20:29, Lennart Poettering pisze: > On Fri, 08.07.16 18:17, Michał Zegan (webczat_...@poczta.onet.pl) wrote: > >> well, that makes sense, thanks. about a timer section shortcut, could it >> be done in a different way? like, it is a shortcut and systemd should >> somehow generate the corresponding timer file automatically? although >> still it would need a little special logic when loading the service >> first. > > I am not convinced that providing two redundant ways to do the same > thing is a good idea. It's bad enough we support both /etc/fstab and > .mount for defining mounts. "Compatibility" is certainly a good enough > excuse to do this anyway in this case. However, if we have two > different ways to configure the same thing with systemd-native file > formats then that's a very different thing and I am very conservative > about really. > > And as mentioned in the other mail: the load logic would become quite > different as we'd have to look for all kinds of unit files if we try > to load a .timer unit. > > Lennart >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel