Michal Schmidt [Fri, 20 Apr 2012 07:38:43 +0000 (09:38 +0200)]
transaction: rework merging with installed jobs
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.
Michal Schmidt [Wed, 18 Apr 2012 16:15:49 +0000 (18:15 +0200)]
transaction: do not add installed jobs to 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.)
Michal Schmidt [Fri, 20 Apr 2012 08:22:07 +0000 (10:22 +0200)]
manager: Transaction as an object
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.
Michal Schmidt [Thu, 19 Apr 2012 21:20:34 +0000 (23:20 +0200)]
job: allow job_free() only on already unlinked jobs
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.
Kay Sievers [Wed, 18 Apr 2012 11:37:45 +0000 (13:37 +0200)]
remove MS_* which can not be combined with current kernel code
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);
systemctl: show main and control PID explicitly in cgroup-show
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.
service: place control command in subcgroup control/
Previously, we were brutally and onconditionally killing all processes
in a service's cgroup before starting the service anew, in order to
ensure that StartPre lines cannot be misused to spawn long-running
processes.
On logind-less systems this has the effect that restarting sshd
necessarily calls all active ssh sessions, which is usually not
desirable.
With this patch control processes for a service are placed in a
sub-cgroup called "control/". When starting a service anew we simply
kill this cgroup, but not the main cgroup, in order to avoid killing any
long-running non-control processes from previous runs.
<kay> walters: you happen to know how to silence this? gudev.h:24: Warning:
GUdev: symbol='_GUDEV_INSIDE_GUDEV_H': Unknown namespace for symbol 'GUDEV_INSIDE_GUDEV_H'
<walters> kay, probably:
<walters> -#define _GUDEV_INSIDE_GUDEV_H 1
<walters> +#define _GUDEV_INSIDE_GUDEV_H
<walters> kay, if the scanner sees a define with a value it assumes it's a constant for public consumption
<walters> kay, patch in https://bugzilla.gnome.org/show_bug.cgi?id=674072 fwiw
<kay> walters: cool, thanks!
<kay> walters: your workaround removing the "1" works. nice!
unit: signal explicitly if a condition failed in unit_start()
We shouldn't print a status message on the console if we skipped a unit
due to a condition. Hence make unit_start() return -ENOEXEC in such a
case which is mapped to JOB_SKIPPED which results in no console message.