On 2015-05-14 at 22:31 +0200, Lennart Poettering wrote: > On Thu, 07.05.15 04:37, Ivan Shapovalov (intelfx...@gmail.com) wrote: > > > On 2015-05-06 at 18:59 +0200, Lennart Poettering wrote: > > > On Wed, 06.05.15 19:53, Andrei Borzenkov (arvidj...@gmail.com) > > > wrote: > > > > > > > I still think that being able to define and start group of > > > > units > > > > as one > > > > unit (pun unintended) is better in the long run. > > > > > > > > This really far exceeds original scope of systemd-run which was > > > > "quickly start something under systemd supervision". When we > > > > have > > > > complex set of units with interdependency either systemd-run is > > > > the > > > > wrong tool for it or it should do it right, not paper over. > > > > > > Hmm, you actually have a point, and we already *do* support > > > queuing > > > groups of units, and that should suffice for this usecase, so > > > that we > > > don't need to allow definiton of reverse deps. > > > > > > This is actually already used for the time-based systemd-run > > > stuff, > > > where we create both a transient timer and a transient service > > > unit > > > and then start the timer unit. > > > > > > Ivan, what you are trying to do hence should already work just > > > fine > > > in > > > the lower level apis, using the "auxiliary" list of units that > > > the > > > StartTransientUnt() bus call takes. systemd-run doesn't > > > generically > > > open this up yet though (and i dont know how it could do so > > > nicely). > > > > Yeah, auxiliary units could help here, though they suffer from the > > same > > kind of problem: either auxiliary units are read from message and > > created before the main one, or vice versa. The problems are the > > same > > as with two consecutive StartTransientUnit calls. > > Hmm, if , I think this should be fixable though. Already, allocating > a > unit, loading a unit and starting a unit are three separate steps. It > shouldn't be too hard to fix PID 1 to allow allocating all transient > units to create in a group first, then in a second step load all of > them, and finally start one of them. With such an order in place it > should be easily possible to do what you want to do, no?
Yeah, makes sense. I'll try to do that in meantime. BTW, regarding creating aux units from systemd-run(1). I guess it can be done in two ways: - "--aux-unit" parameter which adds another aux unit and makes all following parameters (until another --aux-unit) set parameters of this new aux unit (i. e. stateful command line); - "--aux-units-from-file" parameter or something like that which reads the given file and parses each line of it as a separate command line, creating an aux unit from it. The former would look like this: $ systemd-run --name foo.service -p Wants=aux-1.service /bin/foo \ --aux-unit --name aux-1.service -p BindsTo=foo.service /bin/aux-1 The latter (in bash syntax) would look like this: $ systemd-run --name foo.service -p Wants=aux-1.service /bin/foo \ --aux-units-from-file /dev/stdin <<-EOF --name aux-1.service -p BindsTo=foo.service /bin/aux-1 EOF Would any of this be OK? -- Ivan Shapovalov / intelfx /
signature.asc
Description: This is a digitally signed message part
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel