| Age | Commit message (Collapse) | Author |
|---|
|
|
|
While having a Requires= dependency between units, the dependency is started
automatically on "systemctl start", but it's not started on "systemctl
restart".
JOB_RESTART jobs did not pull the dependencies for starting into the
transaction.
https://bugzilla.redhat.com/show_bug.cgi?id=802770
Note that the other bug noted in comment #2 has been fixed already by avoiding
the deletion of anchor jobs.
|
|
Merging of jobs can result in more than one client being interested in a job.
|
|
Transactions cannot contain installed jobs anymore. Remove the now pointless
checks.
|
|
Previously transactions could reference installed jobs. It made some issues
difficult to fix.
This sets new rules for jobs:
A job cannot be both a member of a transaction and installed. When jobs are
created, they are linked to a transaction. The whole transaction is constructed
(with merging of jobs within, etc.). When it's complete, all the jobs are
unlinked from it one by one and let to install themselves. It is during the
installation when merging with previously installed jobs (from older
transactions) is contemplated.
Merging with installed jobs has different rules than merging within a
transaction:
- An installed conflicting job gets cancelled. It cannot be simply deleted,
because someone might be waiting for its completion on DBus.
- An installed, but still waiting, job can be safely merged into.
- An installed and running job can be tricky. For some job types it is safe to
just merge. For the other types we merge anyway, but put the job back into
JOB_WAITING to allow it to run again. This may be suboptimal, but it is not
currently possible to have more than one installed job for a unit.
Note this also fixes a bug where the anchor job could be deleted during merging
within the transaction.
|
|
Let the jobs install themselves.
|
|
We already asserted these facts in the previous loop.
|
|
tr->anchor_job is sufficient.
|
|
Make sure the anchor job is never considered garbage, even if it has no links
leading to it (this will be allowed in the next patch).
|
|
|
|
When isolating, the JOB_STOP jobs have no parent job, so they are all peers
of the real anchor job. This is a bit odd.
Link them from the anchor job.
|
|
Track which job is the anchor in the transaction.
|
|
Do not attempt to optimize away the job creation by refering to installed jobs.
We do not want to disturb installed jobs until commiting the transaction.
(A later patch to job merging will make the separation of transaction jobs and
installed jobs complete.)
|
|
Let the transactions maintain their own anchor links.
|
|
|
|
manager.c takes care of the main loop, unit management, signal handling, ...
transaction.c computes transactions.
After split:
manager.c: 65 KB
transaction.c: 40 KB
|
|
This makes it obvious that transactions are short-lived. They are created in
manager_add_job() and destroyed after the application of jobs.
It also prepares for a split of the transaction code to a new source.
|
|
Split the uninstallation of the job from job_free() into a separate function.
Adjust the callers.
job_free() now only works on unlinked and uninstalled jobs. This enforces clear
thinking about job lifetimes.
|
|
This is equivalent.
|
|
job_free() is IMO too helpful when it unlinks the job from the transaction.
The callers should ensure the job is already unlinked before freeing.
The added assertions check if anyone gets it wrong.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MS_BIND|MS_MOVE can not be combined:
do_mount()
else if (flags & MS_BIND)
do_loopback(&path, dev_name, flags & MS_REC);
[...]
else if (flags & MS_MOVE)
do_move_mount(&path, dev_name);
MS_REMOUNT|MS_UNBINDABLE can not be combined:
do_mount()
if (flags & MS_REMOUNT)
do_remount(&path, flags & ~MS_REMOUNT, mnt_flags, data_page);
[...]
else if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
do_change_type(&path, flags);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In some cases the main/control PID of a service can be outside of the
services cgroups (for example, if logind readjusts the processes'
cgroup). In order to clarify this for the user show the main/control PID
in the cgroup tree nonetheless, but mark them specially.
|
|
|
|
|
|
|
|
|
|
|
|
hierarchy
|
|
|
|
|
|
|
|
|
|
|
