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? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
