diff options
author | Michal Schmidt <mschmidt@redhat.com> | 2012-10-25 02:31:49 +0200 |
---|---|---|
committer | Michal Schmidt <mschmidt@redhat.com> | 2012-10-25 03:21:32 +0200 |
commit | 1abc85b8d026a2d72442b0edaee5213d0ee73c1f (patch) | |
tree | cb53060d8b9af09bb21720d7534349f0e0c70c41 /keymaps/fujitsu-amilo_si_1520 | |
parent | job: add comments to JobResult values (diff) | |
download | systemd-1abc85b8d026a2d72442b0edaee5213d0ee73c1f.tar.xz systemd-1abc85b8d026a2d72442b0edaee5213d0ee73c1f.zip |
job: avoid recursion into transaction code from job cancelation
I hit an "assert(j->installed)" failure in transaction_apply(). Looking
into the backtrace I saw what happened:
1. The system was booting. var.mount/start was an installed job.
2. I pressed Ctrl+Alt+Del.
3. reboot.target was going to be isolated.
4. transaction_apply() proceeded to install a var.mount/stop job.
5. job_install() canceled the conflicting start job.
6. Depending jobs ended recursively with JOB_DEPENDENCY, among them was
local-fs.target/start.
7. Its OnFailure action triggered - emergency.target was now going to be
isolated.
8. We recursed back into transaction_apply() where the half-installed
var.mount/stop job confused us.
Recursing from job installation back into the transaction code cannot be
a good idea. Avoid the problem by canceling the conflicting job
non-recursively in job_install(). I don't think we'll miss anything by
not recursing here. After all, we are called from transaction_apply().
We will not be installing just this one job, but all jobs from a
transaction. All requirement dependencies will be included in it and
will be installed separately. Every transaction job will get a chance
to cancel its own conflicting installed job.
Diffstat (limited to 'keymaps/fujitsu-amilo_si_1520')
0 files changed, 0 insertions, 0 deletions