This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help.
>I don't think having an unit that generates units at runtime is an officially supported use case
Are you sure? Can you tell me how I would find out?
> This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help.
That's the point. Any situation in which you have a system modify itself at runtime is a recipe for a headache. So you do your auto-generation first, then work from a stable state.
> Are you sure? Can you tell me how I would find out?
Aside from that this kind of recursion seems like a great way to get weird problems, and that generators exist for this exact thing, the whole design of systemd discourages this kind of trickery. Units are just supposed to start a command and little else.
Maybe somebody made an official pronouncement on this somewhere, but my personal take on this kind of thing is that it's a bad idea, anywhere, not just systemd.
> Units are just supposed to start a command and little else.
Units are not just for services.
From systemd.unit(5) man page:
> A unit file is a plain text ini-style file that encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd(1), a resource management slice or a group of externally created processes.
>So you do your auto-generation first, then work from a stable state.
You can't do auto generation if that generation depends on the output of some units. Generators can not solve that problem.
>Units are just supposed to start a command and little else.
What a bizarre thing to say. No, that is not just what units are for. I think you are severely misinformed about what systemd is. Units are supposed to take care of ordering accept IPC, define how to handle failures and manage devices.
That comment alone makes me believe that you just do not know what you are talking about at all. It completely misses why systemd is designed the way it is and what it tries to accomplish.
> You can't do auto generation if that generation depends on the output of some units. Generators can not solve that problem.
True
> What a bizarre thing to say. No, that is not just what units are for. I think you are severely misinformed about what systemd is. Units are supposed to take care of ordering accept IPC, define how to handle failures and manage devices.
I mean that part of the point of systemd is that units mostly work out to ExecStart=/usr/bin/binary, and an unit isn't supposed to contain the arbitrary jank one can put into a SysV script.
IPC and the like is an explicit systemd feature, not something you improvise behind the scenes and then expect to work anyway.
I don't think having an unit that generates units at runtime is an officially supported use case, since generators exist.