> > > > Up to v206, the behavior of systemd was the following one: > > ---------------------------------------------------------- > > - the starter sends out a start request of a bench of applications > (he requests a sequence of unit starts) > > If you want to control order of execution yourself, why do you not wait > for each unit to start before submitting next request?
The synchronization point is not 'Unit started' but 'Job started'. I'm searching for a good solution to detect that. > > So long story in advance. I've now two questions: > > - Am I causing any critical side effects when I'm increasing the run > queue priority so that it is higher than the one of the dbus handling > (which is NORMAL)? First tests showed that I can get back exactly the > behavior we had before with that. > > > > - Might it still happen that situations are happening where the jobs > are reordered even though I'm increasing the priority? > > > > - Is there any other good solution ensuring the order of job > execution? > > > > systemd never promised anything about relative order of execution > unless there is explicit dependency between units. So good solution is > to put dependency in unit definitions. submit the whole bunch at once > and let systemd sort the order. Understood and agreed ;) Dependency is not an option because the synchronization point is not 'Unit Started' but 'Job kicked off' for the sequence. The sync point 'Unit Started' is need for "real" dependencies. However, has anyone an opinion on the first idea? (increasing the priority) I'd be interested in side effects caused by this modification. Thx, Marko _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
