On Thu, 27.01.11 06:57, Andrey Borzenkov ([email protected]) wrote: > I request to start unit - "systemctl start foo.target". This computes > foo dependencies and requirements and initiate transaction. What > happens if another request (say, systemctl start bar.target) comes > while the first one is still being processed? In this case foo and bar > are two completely separate units that do not have anything in common, > and actions can be start or stop - again it does not matter. > > To be more precise - will systemd wait until foo.target with all > dependencies is started or will it initiate bar.target transaction in > parallel while foo.target is still running?
If you enqueue multiple transactions one after the other, then systemd will happily do so and execute them in parallel, but following the ordering deps between the jobs, even if they got enqueued by different transactions. If the jobs of two transactions are contradicting each other (e.g. you alread enqueded "start foo.service" and now try to enqueue "stop foo.service") then the later transaction wins, unless you pass --fail to systemcl when enqueuing it in which case the second transaction will not be installed at all and hence fail. Note that systemd has a very weak definition of "transaction": it is relevant only up to the time where the transaction has been successfully enqueued. as soon as that happened the transaction context is dropped. That basically means that when you start a unit and this pulls in depending units, then either they all will be enqueued or none of them if that wasnt possible. so, what this all means in real life is that when the inital boot transaction is being executed and while that happens via bus or socket activation another job is enqueued, then this will work just fine and the jobs of that second transaction will be enqueued and executed right-away and as parallelized as possible, with the same priority and timeliness as the jobs of the initial boot transaction itself. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
