[systemd-devel] Are transactions (state change requests) serialized?

[Lennart Poettering]

On Thu, 27.01.11 06:57, Andrey Borzenkov (arvidjaar at gmail.com) 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.