| Age | Commit message (Collapse) | Author |
|---|
|
This breaks D-Bus interface slightly, but since the D-Bus API isn't
covered by the interface stability promise this should be OK.
|
|
The kernel will only notify us of cgroups running empty if no subcgroups
exist anymore. Hence make sure we don't leave our own control/ subcgroup
around longer than necessary.
https://bugzilla.redhat.com/show_bug.cgi?id=818381
|
|
|
|
|
|
|
|
RequiresMountsFor= is a shortcut for adding requires and after
dependencies to all mount units neeed for the specified paths.
This solves a couple of issues regarding dep loop cycles for encrypted
swap.
|
|
Two of our current job types are special:
JOB_TRY_RESTART, JOB_RELOAD_OR_START.
They differ from other job types by being sensitive to the unit active state.
They perform some action when the unit is active and some other action
otherwise. This raises a question: when exactly should the unit state be
checked to make the decision?
Currently the unit state is checked when the job becomes runnable. It's more
sensible to check the state immediately when the job is added by the user.
When the user types "systemctl try-restart foo.service", he really intends
to restart the service if it's running right now. If it isn't running right
now, the restart is pointless.
Consider the example (from Bugzilla[1]):
sleep.service takes some time to start.
hello.service has After=sleep.service.
Both services get started. Two jobs will appear:
hello.service/start waiting
sleep.service/start running
Then someone runs "systemctl try-restart hello.service".
Currently the try-restart operation will block and wait for
sleep.service/start to complete.
The correct result is to complete the try-restart operation immediately
with success, because hello.service is not running. The two original
jobs must not be disturbed by this.
To fix this we introduce two new concepts:
- a new job type: JOB_NOP
A JOB_NOP job does not do anything to the unit. It does not pull in any
dependencies. It is always immediately runnable. When installed to a unit,
it sits in a special slot (u->nop_job) where it never conflicts with
the installed job (u->job) of a different type. It never merges with jobs
of other types, but it can merge into an already installed JOB_NOP job.
- "collapsing" of job types
When a job of one of the two special types is added, the state of the unit
is checked immediately and the job type changes:
JOB_TRY_RESTART -> JOB_RESTART or JOB_NOP
JOB_RELOAD_OR_START -> JOB_RELOAD or JOB_START
Should a job type JOB_RELOAD_OR_START appear later during job merging, it
collapses immediately afterwards.
Collapsing actually makes some things simpler, because there are now fewer
job types that are allowed in the transaction.
[1] Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=753586
|
|
shutdowns clean
|
|
This has the advantage of removing a confusing warning by mount if the
root directory is not listed in fstab.
|
|
Type=idle is much like Type=simple, however between the fork() and the
exec() in the child we wait until PID 1 informs us that no jobs are
left.
This is mostly a cosmetic fix to make gettys appear only after all boot
output is finished and complete.
Note that this does not impact the normal job logic as we do not delay
the completion of any jobs. We just delay the invocation of the actual
binary, and only for services that otherwise would be of Type=simple.
|
|
The ability to set MountAuto=no and SwapAuto=no was useful during the
adoption phase of systemd, so that distributions could stick to their
classic mount scripts a bit longer. It is about time to get rid of it
now.
|
|
Recursive cancellation of jobs would trigger OnFailure actions of
dependent jobs. This is not desirable when isolating.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=798328
|
|
Jobs were not preserved correctly over a daemon-reload operation.
A systemctl process waiting for a job completion received a job removal
signal. The job itself changed its id. The job timeout started ticking all
over again.
This fixes the deficiencies.
|
|
Recursion is unnecessary, because we're deleting all transaction jobs
anyway. And the recursive deletion produces debug messages that are
pointless in transaction abort.
|
|
A transaction can be acyclic, but when it's added to installed jobs,
a cycle may result.
transaction_verify_order_one() attempts to detect these cases, but it
fails because the installed jobs often have the exact generation number
that makes them look as if they were walked already.
Fix it by resetting the generation numbers of all installed jobs before
detecting cycles.
An alternative fix could be to add the generation counter to the
Manager and use it instead of starting always from 1 in
transaction_activate(). But I prefer not having to worry about it
wrapping around.
|
|
The functions looked complicated with the nested loops with breaks,
continues, and "while (again)".
Here using goto actually makes them easier to understand.
Also correcting the comment about redundant jobs.
|
|
|
|
complain
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/sys/class/tty/console/active is misleading
|
|
|
|
|
|
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);
|
