Hi Something like this would be valuable for network interface services. Would be nice to be able to write a generic "udhcpc@" service, and then instantiate "udhcpc@eth0" and "udhcpc@eth1".
My 0.02$. /Esben On 13 January 2016 at 18:50, Olivier Brunel <[email protected]> wrote: > On Fri, 25 Dec 2015 11:43:31 +0100 > Laurent Bercot <[email protected]> wrote: > >> Hello everyone, and happy holidays! >> >> In the past few years, there have been some bits and pieces of >> discussion about "instanced services", i.e. some kind of supervised >> service that would be able to create different instances of the >> process at will. But it never got very detailed. >> >> I'd like to ask you: if you feel that instanced services are >> useful, what functionality would you like to see ? Concretely, >> practically, what do you want to be able to do ? >> >> Please stay away from mechanism and implementation details; >> I'm just trying to get a very high-level, conceptual feel for it >> at the moment - "what", as opposed to "how". >> >> Thanks ! >> > > Hey, > > So I'm not sure this is what you're thinking of, but I can describe > what "instanced services" are with regards to anopa; And that's > basically just a way to use the same servicedir for multiple services, > or more exactly only create/manage a single servicedir, but be able to > use it for more than one services (or instances). > > Can be helpful when you have multiple instances of "the same"/similar > services, where the only difference would be an argument to the daemon > or something to that effect. > > This gets into mechanism I'm afraid, but I'm not sure how to best > explain it otherwise: servicedirs would be created/managed in a > sourcedir, and enabling (or compiling, might be the equivalent in > s6-rc) means pretty much copying the servicedir from the sourcedir into > the scandir (or compiled, or whatever), where it becomes "active"/in > use. > > With instanced services, it means when you enable such a service you > add/specify an instance name. So e.g. the servicedir is "getty@" but > you enable "getty@tty2" -- which just means the servicedir getty@ is > copied under a different name in the scandir. > > The intent being that to enable another getty, you just enable > getty@tty3 and that's it. One actual servicedir is being maintained, > but used many times (as different instances, which really are > different services in the end). If you need to fix/change the > servicedir, it's done once and then applied to all instances. > > (Obviously the scripts (e.g. run) needs a way to use the instance name, > as that usually ends up being an argument to the daemon, or to point > to/read from a different config directory, etc) > > Note that this actually isn't limited to longruns, but also works for > oneshots. Hence why I'm thinking this might be different to what you're > thinking of. > > Anyhow, HTH > -j -- Esben Haabendal Ulstrupvej 7, 9500 Hobro, Denmark
