picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Systemd/src/core/job.c

1695 lines
56 KiB
C
Raw Normal View History

Add SPDX license identifiers to source files under the LGPL This follows what the kernel is doing, c.f. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fd54ace4721fc5ce2bb5aef6318fcf17f421460.
2017-11-18 17:09:20 +01:00
/* SPDX-License-Identifier: LGPL-2.1+ */
license: add GPLv2+ license blurbs everwhere
2010-02-03 13:03:47 +01:00
fix job merging
2010-01-21 00:51:37 +01:00
#include <errno.h>
initial commit
2009-11-18 00:42:52 +01:00
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
#include "sd-id128.h"
#include "sd-messages.h"
util: split out escaping code into escape.[ch] This really deserves its own file, given how much code this is now.
2015-10-23 18:52:53 +02:00
util-lib: split out allocation calls into alloc-util.[ch]
2015-10-27 03:01:06 +01:00
#include "alloc-util.h"
Make tmpdir removal asynchronous https://bugs.freedesktop.org/show_bug.cgi?id=68232
2013-09-16 22:50:38 +02:00
#include "async.h"
util: split out escaping code into escape.[ch] This really deserves its own file, given how much code this is now.
2015-10-23 18:52:53 +02:00
#include "dbus-job.h"
bus: add sd_bus_track object for tracking peers, and port core over to it This is primarily useful for services that need to track clients which reference certain objects they maintain, or which explicitly want to subscribe to certain events. Something like this is done in a large number of services, and not trivial to do. Hence, let's unify this at one place. This also ports over PID 1 to use this to ensure that subscriptions to job and manager events are correctly tracked. As a side-effect this makes sure we properly serialize and restore the track list across daemon reexec/reload, which didn't work correctly before. This also simplifies how we distribute messages to broadcast to the direct busses: we only track subscriptions for the API bus and implicitly assume that all direct busses are subscribed. This should be a pretty OK simplification since clients connected via direct bus connections are shortlived anyway.
2014-03-03 01:33:45 +01:00
#include "dbus.h"
util: split out escaping code into escape.[ch] This really deserves its own file, given how much code this is now.
2015-10-23 18:52:53 +02:00
#include "escape.h"
core: when deserializing state always use read_line(…, LONG_LINE_MAX, …) This should be much better than fgets(), as we can read substantially longer lines and overly long lines result in proper errors. Fixes a vulnerability discovered by Jann Horn at Google. CVE-2018-15686 LP: #1796402 https://bugzilla.redhat.com/show_bug.cgi?id=1639071
2018-10-17 18:36:24 +02:00
#include "fileio.h"
util-lib: split string parsing related calls from util.[ch] into parse-util.[ch]
2015-10-26 16:18:16 +01:00
#include "job.h"
util: split out escaping code into escape.[ch] This really deserves its own file, given how much code this is now.
2015-10-23 18:52:53 +02:00
#include "log.h"
#include "macro.h"
util-lib: split string parsing related calls from util.[ch] into parse-util.[ch]
2015-10-26 16:18:16 +01:00
#include "parse-util.h"
core: rework serialization Let's be more careful with what we serialize: let's ensure we never serialize strings that are longer than LONG_LINE_MAX, so that we know we can read them back with read_line(…, LONG_LINE_MAX, …) safely. In order to implement this all serialization functions are move to serialize.[ch], and internally will do line size checks. We'd rather skip a serialization line (with a loud warning) than write an overly long line out. Of course, this is just a second level protection, after all the data we serialize shouldn't be this long in the first place. While we are at it also clean up logging: while serializing make sure to always log about errors immediately. Also, (void)ify all calls we don't expect errors in (or catch errors as part of the general fflush_and_check() at the end.
2018-10-17 20:40:09 +02:00
#include "serialize.h"
util: split out escaping code into escape.[ch] This really deserves its own file, given how much code this is now.
2015-10-23 18:52:53 +02:00
#include "set.h"
util: split out sorting related calls to new sort-util.[ch]
2019-03-13 12:14:47 +01:00
#include "sort-util.h"
util: split out escaping code into escape.[ch] This really deserves its own file, given how much code this is now.
2015-10-23 18:52:53 +02:00
#include "special.h"
tree-wide: use xsprintf() where applicable Also add a coccinelle receipt to help with such transitions.
2016-01-12 15:34:20 +01:00
#include "stdio-util.h"
util-lib: move string table stuff into its own string-table.[ch]
2015-10-26 22:31:05 +01:00
#include "string-table.h"
util-lib: split our string related calls from util.[ch] into its own file string-util.[ch] There are more than enough calls doing string manipulations to deserve its own files, hence do something about it. This patch also sorts the #include blocks of all files that needed to be updated, according to the sorting suggestions from CODING_STYLE. Since pretty much every file needs our string manipulation functions this effectively means that most files have sorted #include blocks now. Also touches a few unrelated include files.
2015-10-24 22:58:24 +02:00
#include "string-util.h"
util: split out escaping code into escape.[ch] This really deserves its own file, given how much code this is now.
2015-10-23 18:52:53 +02:00
#include "strv.h"
shared: add terminal-util.[ch]
2015-04-10 23:15:59 +02:00
#include "terminal-util.h"
util: split out escaping code into escape.[ch] This really deserves its own file, given how much code this is now.
2015-10-23 18:52:53 +02:00
#include "unit.h"
#include "virt.h"
dbus-job: allow multiple bus clients Merging of jobs can result in more than one client being interested in a job.
2012-04-20 12:28:31 +02:00
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
Job* job_new_raw(Unit *unit) {
initial commit
2009-11-18 00:42:52 +01:00
Job *j;
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
/* used for deserialization */
s/name/unit
2010-01-26 21:39:06 +01:00
assert(unit);
initial commit
2009-11-18 00:42:52 +01:00
job: use structured initialization
2018-10-17 19:07:15 +02:00
j = new(Job, 1);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
if (!j)
initial commit
2009-11-18 00:42:52 +01:00
return NULL;
job: use structured initialization
2018-10-17 19:07:15 +02:00
*j = (Job) {
.manager = unit->manager,
.unit = unit,
.type = _JOB_TYPE_INVALID,
};
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
return j;
}
Job* job_new(Unit *unit, JobType type) {
Job *j;
assert(type < _JOB_TYPE_MAX);
j = job_new_raw(unit);
if (!j)
return NULL;
j->id = j->manager->current_job_id++;
j->type = type;
implement transaction engine
2010-01-20 02:12:51 +01:00
/* We don't link it here, that's what job_dependency() is for */
initial commit
2009-11-18 00:42:52 +01:00
return j;
}
fix race between daemon-reload and other commands When "systemctl daemon-reload" is run at the same time as "systemctl start foo", the latter might hang. That's because commands like start wait for JobRemoved signal to know when the job is finished. But if the job is finished during reloading, the signal is never sent. The hang can be easily reproduced by running # for ((N=1; N>0; N++)) ; do echo $N ; systemctl daemon-reload ; done # for ((N=1; N>0; N++)) ; do echo $N ; systemctl start systemd-coredump.socket ; done in two different terminals. The start command will hang after 1-2 iterations. This keeps track of jobs that were started before reload and finished during it and sends JobRemoved after the reload has finished.
2018-04-24 15:19:38 +02:00
void job_unlink(Job *j) {
job: job_uninstall() 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.
2012-04-20 10:21:37 +02:00
assert(j);
assert(!j->installed);
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.
2012-04-19 23:20:34 +02:00
assert(!j->transaction_prev);
assert(!j->transaction_next);
assert(!j->subject_list);
assert(!j->object_list);
initial commit
2009-11-18 00:42:52 +01:00
fix race between daemon-reload and other commands When "systemctl daemon-reload" is run at the same time as "systemctl start foo", the latter might hang. That's because commands like start wait for JobRemoved signal to know when the job is finished. But if the job is finished during reloading, the signal is never sent. The hang can be easily reproduced by running # for ((N=1; N>0; N++)) ; do echo $N ; systemctl daemon-reload ; done # for ((N=1; N>0; N++)) ; do echo $N ; systemctl start systemd-coredump.socket ; done in two different terminals. The start command will hang after 1-2 iterations. This keeps track of jobs that were started before reload and finished during it and sends JobRemoved after the reload has finished.
2018-04-24 15:19:38 +02:00
if (j->in_run_queue) {
list: make our list macros a bit easier to use by not requring type spec on each invocation We can determine the list entry type via the typeof() gcc construct, and so we should to make the macros much shorter to use.
2013-10-14 06:10:14 +02:00
LIST_REMOVE(run_queue, j->manager->run_queue, j);
fix race between daemon-reload and other commands When "systemctl daemon-reload" is run at the same time as "systemctl start foo", the latter might hang. That's because commands like start wait for JobRemoved signal to know when the job is finished. But if the job is finished during reloading, the signal is never sent. The hang can be easily reproduced by running # for ((N=1; N>0; N++)) ; do echo $N ; systemctl daemon-reload ; done # for ((N=1; N>0; N++)) ; do echo $N ; systemctl start systemd-coredump.socket ; done in two different terminals. The start command will hang after 1-2 iterations. This keeps track of jobs that were started before reload and finished during it and sends JobRemoved after the reload has finished.
2018-04-24 15:19:38 +02:00
j->in_run_queue = false;
}
dbus: send out signals when units/jobs come, go and change
2010-02-05 00:38:41 +01:00
fix race between daemon-reload and other commands When "systemctl daemon-reload" is run at the same time as "systemctl start foo", the latter might hang. That's because commands like start wait for JobRemoved signal to know when the job is finished. But if the job is finished during reloading, the signal is never sent. The hang can be easily reproduced by running # for ((N=1; N>0; N++)) ; do echo $N ; systemctl daemon-reload ; done # for ((N=1; N>0; N++)) ; do echo $N ; systemctl start systemd-coredump.socket ; done in two different terminals. The start command will hang after 1-2 iterations. This keeps track of jobs that were started before reload and finished during it and sends JobRemoved after the reload has finished.
2018-04-24 15:19:38 +02:00
if (j->in_dbus_queue) {
list: make our list macros a bit easier to use by not requring type spec on each invocation We can determine the list entry type via the typeof() gcc construct, and so we should to make the macros much shorter to use.
2013-10-14 06:10:14 +02:00
LIST_REMOVE(dbus_queue, j->manager->dbus_job_queue, j);
fix race between daemon-reload and other commands When "systemctl daemon-reload" is run at the same time as "systemctl start foo", the latter might hang. That's because commands like start wait for JobRemoved signal to know when the job is finished. But if the job is finished during reloading, the signal is never sent. The hang can be easily reproduced by running # for ((N=1; N>0; N++)) ; do echo $N ; systemctl daemon-reload ; done # for ((N=1; N>0; N++)) ; do echo $N ; systemctl start systemd-coredump.socket ; done in two different terminals. The start command will hang after 1-2 iterations. This keeps track of jobs that were started before reload and finished during it and sends JobRemoved after the reload has finished.
2018-04-24 15:19:38 +02:00
j->in_dbus_queue = false;
}
dbus: send out signals when units/jobs come, go and change
2010-02-05 00:38:41 +01:00
fix race between daemon-reload and other commands When "systemctl daemon-reload" is run at the same time as "systemctl start foo", the latter might hang. That's because commands like start wait for JobRemoved signal to know when the job is finished. But if the job is finished during reloading, the signal is never sent. The hang can be easily reproduced by running # for ((N=1; N>0; N++)) ; do echo $N ; systemctl daemon-reload ; done # for ((N=1; N>0; N++)) ; do echo $N ; systemctl start systemd-coredump.socket ; done in two different terminals. The start command will hang after 1-2 iterations. This keeps track of jobs that were started before reload and finished during it and sends JobRemoved after the reload has finished.
2018-04-24 15:19:38 +02:00
if (j->in_gc_queue) {
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
LIST_REMOVE(gc_queue, j->manager->gc_job_queue, j);
fix race between daemon-reload and other commands When "systemctl daemon-reload" is run at the same time as "systemctl start foo", the latter might hang. That's because commands like start wait for JobRemoved signal to know when the job is finished. But if the job is finished during reloading, the signal is never sent. The hang can be easily reproduced by running # for ((N=1; N>0; N++)) ; do echo $N ; systemctl daemon-reload ; done # for ((N=1; N>0; N++)) ; do echo $N ; systemctl start systemd-coredump.socket ; done in two different terminals. The start command will hang after 1-2 iterations. This keeps track of jobs that were started before reload and finished during it and sends JobRemoved after the reload has finished.
2018-04-24 15:19:38 +02:00
j->in_gc_queue = false;
}
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
fix race between daemon-reload and other commands When "systemctl daemon-reload" is run at the same time as "systemctl start foo", the latter might hang. That's because commands like start wait for JobRemoved signal to know when the job is finished. But if the job is finished during reloading, the signal is never sent. The hang can be easily reproduced by running # for ((N=1; N>0; N++)) ; do echo $N ; systemctl daemon-reload ; done # for ((N=1; N>0; N++)) ; do echo $N ; systemctl start systemd-coredump.socket ; done in two different terminals. The start command will hang after 1-2 iterations. This keeps track of jobs that were started before reload and finished during it and sends JobRemoved after the reload has finished.
2018-04-24 15:19:38 +02:00
j->timer_event_source = sd_event_source_unref(j->timer_event_source);
}
job: update job_free() to follow our usual return-NULL style
2018-12-10 18:52:11 +01:00
Job* job_free(Job *j) {
fix race between daemon-reload and other commands When "systemctl daemon-reload" is run at the same time as "systemctl start foo", the latter might hang. That's because commands like start wait for JobRemoved signal to know when the job is finished. But if the job is finished during reloading, the signal is never sent. The hang can be easily reproduced by running # for ((N=1; N>0; N++)) ; do echo $N ; systemctl daemon-reload ; done # for ((N=1; N>0; N++)) ; do echo $N ; systemctl start systemd-coredump.socket ; done in two different terminals. The start command will hang after 1-2 iterations. This keeps track of jobs that were started before reload and finished during it and sends JobRemoved after the reload has finished.
2018-04-24 15:19:38 +02:00
assert(j);
assert(!j->installed);
assert(!j->transaction_prev);
assert(!j->transaction_next);
assert(!j->subject_list);
assert(!j->object_list);
job_unlink(j);
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
core: rename "clients" field of Job structure to "bus_track" Let's make semantics of this field more similar to the same functionality in the Unit object, in particular as we add new functionality to it later on.
2016-11-15 19:29:50 +01:00
sd_bus_track_unref(j->bus_track);
core: Rename Job.subscribed field to Job.clients This reflects how this field will be used, to not only track where to send signals, but also which callers (other than root) are allowed to call DBus methods on the Job.
2014-08-06 11:53:00 +02:00
strv_free(j->deserialized_clients);
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
job: update job_free() to follow our usual return-NULL style
2018-12-10 18:52:11 +01:00
return mfree(j);
initial commit
2009-11-18 00:42:52 +01:00
}
add functions for dumping server state
2010-01-19 00:22:34 +01:00
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
static void job_set_state(Job *j, JobState state) {
assert(j);
assert(state >= 0);
assert(state < _JOB_STATE_MAX);
if (j->state == state)
return;
j->state = state;
if (!j->installed)
return;
if (j->state == JOB_RUNNING)
j->unit->manager->n_running_jobs++;
else {
assert(j->state == JOB_WAITING);
assert(j->unit->manager->n_running_jobs > 0);
j->unit->manager->n_running_jobs--;
if (j->unit->manager->n_running_jobs <= 0)
j->unit->manager->jobs_in_progress_event_source = sd_event_source_unref(j->unit->manager->jobs_in_progress_event_source);
}
}
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
void job_uninstall(Job *j) {
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
Job **pj;
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
assert(j->installed);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
job_set_state(j, JOB_WAITING);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
pj = (j->type == JOB_NOP) ? &j->unit->nop_job : &j->unit->job;
assert(*pj == j);
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
/* Detach from next 'bigger' objects */
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
/* daemon-reload should be transparent to job observers */
core: introduce MANAGER_IS_RELOADING() macro This replaces the old function call manager_is_reloading_or_reexecuting() which was used only at very few places. Use the new macro wherever we check whether we are reloading. This should hopefully make things a bit more readable, given the nature of Manager:n_reloading being a counter.
2016-02-24 21:36:09 +01:00
if (!MANAGER_IS_RELOADING(j->manager))
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
bus_job_send_removed_signal(j);
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
*pj = NULL;
transaction: remove checks for installed Transactions cannot contain installed jobs anymore. Remove the now pointless checks.
2012-04-20 10:02:05 +02:00
unit_add_to_gc_queue(j->unit);
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
core: when we uninstall a job, add unit to dbus queue Commit e6d05912cb1785d8c75eb40545beb8a7c6753cb9 added unit to dbus queue on job install. Do same on job uninstall to make sure we get PropertiesChanged signal.
2019-02-12 02:00:21 +01:00
unit_add_to_dbus_queue(j->unit); /* The Job property of the unit has changed now */
job: be more careful when removing job object from jobs hash table Let's validate that the ID is actually allocated to us before remove a job. This is relevant as various bits of code will call job_free() on partially set up Job objects, and we really shouldn't remove another job object accidentally from the hash table, when the set up didn't complete.
2018-12-10 19:38:38 +01:00
hashmap_remove_value(j->manager->jobs, UINT32_TO_PTR(j->id), j);
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
j->installed = false;
}
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.
2012-04-20 09:38:43 +02:00
static bool job_type_allows_late_merge(JobType t) {
/* Tells whether it is OK to merge a job of type 't' with an already
* running job.
* Reloads cannot be merged this way. Think of the sequence:
* 1. Reload of a daemon is in progress; the daemon has already loaded
* its config file, but hasn't completed the reload operation yet.
* 2. Edit foo's config file.
* 3. Trigger another reload to have the daemon use the new config.
* Should the second reload job be merged into the first one, the daemon
* would not know about the new config.
* JOB_RESTART jobs on the other hand can be merged, because they get
* patched into JOB_START after stopping the unit. So if we see a
* JOB_RESTART running, it means the unit hasn't stopped yet and at
* this time the merge is still allowed. */
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
return t != JOB_RELOAD;
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.
2012-04-20 09:38:43 +02:00
}
static void job_merge_into_installed(Job *j, Job *other) {
assert(j->installed);
assert(j->unit == other->unit);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
if (j->type != JOB_NOP)
core/job: add check for return of job_type_merge_and_collapse() Using an assertion is fine, since calls to job_merge_into_installed() are protected by a check for job_type_is_conflicting(). Uncovered by Coverity, fixes CID 996307.
2018-06-12 23:20:04 +02:00
assert_se(job_type_merge_and_collapse(&j->type, other->type, j->unit) == 0);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
else
assert(other->type == JOB_NOP);
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.
2012-04-20 09:38:43 +02:00
core, systemctl: add support for irreversible jobs Add a new job mode: replace-irreversibly. Jobs enqueued using this mode cannot be implicitly canceled by later enqueued conflicting jobs. They can however still be canceled with an explicit "systemctl cancel" call.
2013-02-22 11:21:37 +01:00
j->irreversible = j->irreversible || other->irreversible;
job: fix merging with --ignore-dependencies This fixes a bug where a job with --ignore-dependencies would wait for other jobs because it merged into a previously queued job.
2013-01-25 19:54:21 +01:00
j->ignore_order = j->ignore_order || other->ignore_order;
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.
2012-04-20 09:38:43 +02:00
}
Job* job_install(Job *j) {
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
Job **pj;
Job *uj;
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
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.
2012-04-20 09:38:43 +02:00
assert(!j->installed);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
assert(j->type < _JOB_TYPE_MAX_IN_TRANSACTION);
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
assert(j->state == JOB_WAITING);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
pj = (j->type == JOB_NOP) ? &j->unit->nop_job : &j->unit->job;
uj = *pj;
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.
2012-04-20 09:38:43 +02:00
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
if (uj) {
core: drop now-redundant special-casing of JOB_NOP job_type_is_conflicting(X, JOB_NOP) correctly gives: false. job_type_allows_late_merge(JOB_NOP) && job_type_is_superset(X, JOB_NOP) correctly gives: true.
2014-11-26 16:33:45 +01:00
if (job_type_is_conflicting(uj->type, j->type))
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
job_finish_and_invalidate(uj, JOB_CANCELED, false, false);
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.
2012-04-20 09:38:43 +02:00
else {
/* not conflicting, i.e. mergeable */
core: drop now-redundant special-casing of JOB_NOP job_type_is_conflicting(X, JOB_NOP) correctly gives: false. job_type_allows_late_merge(JOB_NOP) && job_type_is_superset(X, JOB_NOP) correctly gives: true.
2014-11-26 16:33:45 +01:00
if (uj->state == JOB_WAITING ||
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.
2012-04-20 09:38:43 +02:00
(job_type_allows_late_merge(j->type) && job_type_is_superset(uj->type, j->type))) {
job_merge_into_installed(uj, j);
core,network: major per-object logging rework This changes log_unit_info() (and friends) to take a real Unit* object insted of just a unit name as parameter. The call will now prefix all logged messages with the unit name, thus allowing the unit name to be dropped from the various passed romat strings, simplifying invocations drastically, and unifying log output across messages. Also, UNIT= vs. USER_UNIT= is now derived from the Manager object attached to the Unit object, instead of getpid(). This has the benefit of correcting the field for --test runs. Also contains a couple of other logging improvements: - Drops a couple of strerror() invocations in favour of using %m. - Not only .mount units now warn if a symlinks exist for the mount point already, .automount units do that too, now. - A few invocations of log_struct() that didn't actually pass any additional structured data have been replaced by simpler invocations of log_unit_info() and friends. - For structured data a new LOG_UNIT_MESSAGE() macro has been added, that works like LOG_MESSAGE() but prefixes the message with the unit name. Similar, there's now LOG_LINK_MESSAGE() and LOG_NETDEV_MESSAGE(). - For structured data new LOG_UNIT_ID(), LOG_LINK_INTERFACE(), LOG_NETDEV_INTERFACE() macros have been added that generate the necessary per object fields. The old log_unit_struct() call has been removed in favour of these new macros used in raw log_struct() invocations. In addition to removing one more function call this allows generated structured log messages that contain two object fields, as necessary for example for network interfaces that are joined into another network interface, and whose messages shall be indexed by both. - The LOG_ERRNO() macro has been removed, in favour of log_struct_errno(). The latter has the benefit of ensuring that %m in format strings is properly resolved to the specified error number. - A number of logging messages have been converted to use log_unit_info() instead of log_info() - The client code in sysv-generator no longer #includes core code from src/core/. - log_unit_full_errno() has been removed, log_unit_full() instead takes an errno now, too. - log_unit_info(), log_link_info(), log_netdev_info() and friends, now avoid double evaluation of their parameters
2015-05-11 20:38:21 +02:00
log_unit_debug(uj->unit,
Log the job being merged Makes it easier to understand what was merged (and easier to realize why). Example is a start job running, and another unit triggering a verify-active job. It is not clear what job was it that from baz.service that merged into the installed job for bar.service in the debug logs. This makes it useful when debugging issues. Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Trying to enqueue job baz.service/start/replace Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Installed new job baz.service/start as 498 Jan 15 11:45:58 jupiter systemd[1218]: bar.service: Merged into installed job bar.service/start as 497 Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Enqueued job baz.service/start as 498 It becomes: Jan 15 11:45:58 jupiter systemd[1218]: bar.service: Merged bar.service/verify-active into installed job bar.service/start as 497
2019-01-16 01:03:22 +01:00
"Merged %s/%s into installed job %s/%s as %"PRIu32,
tree-wide: fix some trailing whitespace @bl33pbl0p, please fix your editor (Apparently you never configured the source tree? If you did, then the git pre-commit hook would have been enabled which doesn't allow commiting non-whitespace clean stuff...)
2019-01-17 19:47:19 +01:00
j->unit->id, job_type_to_string(j->type), uj->unit->id,
Log the job being merged Makes it easier to understand what was merged (and easier to realize why). Example is a start job running, and another unit triggering a verify-active job. It is not clear what job was it that from baz.service that merged into the installed job for bar.service in the debug logs. This makes it useful when debugging issues. Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Trying to enqueue job baz.service/start/replace Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Installed new job baz.service/start as 498 Jan 15 11:45:58 jupiter systemd[1218]: bar.service: Merged into installed job bar.service/start as 497 Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Enqueued job baz.service/start as 498 It becomes: Jan 15 11:45:58 jupiter systemd[1218]: bar.service: Merged bar.service/verify-active into installed job bar.service/start as 497
2019-01-16 01:03:22 +01:00
job_type_to_string(uj->type), uj->id);
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.
2012-04-20 09:38:43 +02:00
return uj;
} else {
/* already running and not safe to merge into */
/* Patch uj to become a merged job and re-run it. */
/* XXX It should be safer to queue j to run after uj finishes, but it is
* not currently possible to have more than one installed job per unit. */
job_merge_into_installed(uj, j);
core,network: major per-object logging rework This changes log_unit_info() (and friends) to take a real Unit* object insted of just a unit name as parameter. The call will now prefix all logged messages with the unit name, thus allowing the unit name to be dropped from the various passed romat strings, simplifying invocations drastically, and unifying log output across messages. Also, UNIT= vs. USER_UNIT= is now derived from the Manager object attached to the Unit object, instead of getpid(). This has the benefit of correcting the field for --test runs. Also contains a couple of other logging improvements: - Drops a couple of strerror() invocations in favour of using %m. - Not only .mount units now warn if a symlinks exist for the mount point already, .automount units do that too, now. - A few invocations of log_struct() that didn't actually pass any additional structured data have been replaced by simpler invocations of log_unit_info() and friends. - For structured data a new LOG_UNIT_MESSAGE() macro has been added, that works like LOG_MESSAGE() but prefixes the message with the unit name. Similar, there's now LOG_LINK_MESSAGE() and LOG_NETDEV_MESSAGE(). - For structured data new LOG_UNIT_ID(), LOG_LINK_INTERFACE(), LOG_NETDEV_INTERFACE() macros have been added that generate the necessary per object fields. The old log_unit_struct() call has been removed in favour of these new macros used in raw log_struct() invocations. In addition to removing one more function call this allows generated structured log messages that contain two object fields, as necessary for example for network interfaces that are joined into another network interface, and whose messages shall be indexed by both. - The LOG_ERRNO() macro has been removed, in favour of log_struct_errno(). The latter has the benefit of ensuring that %m in format strings is properly resolved to the specified error number. - A number of logging messages have been converted to use log_unit_info() instead of log_info() - The client code in sysv-generator no longer #includes core code from src/core/. - log_unit_full_errno() has been removed, log_unit_full() instead takes an errno now, too. - log_unit_info(), log_link_info(), log_netdev_info() and friends, now avoid double evaluation of their parameters
2015-05-11 20:38:21 +02:00
log_unit_debug(uj->unit,
Log the job being merged Makes it easier to understand what was merged (and easier to realize why). Example is a start job running, and another unit triggering a verify-active job. It is not clear what job was it that from baz.service that merged into the installed job for bar.service in the debug logs. This makes it useful when debugging issues. Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Trying to enqueue job baz.service/start/replace Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Installed new job baz.service/start as 498 Jan 15 11:45:58 jupiter systemd[1218]: bar.service: Merged into installed job bar.service/start as 497 Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Enqueued job baz.service/start as 498 It becomes: Jan 15 11:45:58 jupiter systemd[1218]: bar.service: Merged bar.service/verify-active into installed job bar.service/start as 497
2019-01-16 01:03:22 +01:00
"Merged into running job, re-running: %s/%s as %"PRIu32,
uj->unit->id, job_type_to_string(uj->type), uj->id);
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
job_set_state(uj, JOB_WAITING);
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.
2012-04-20 09:38:43 +02:00
return uj;
}
}
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
}
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.
2012-04-20 09:38:43 +02:00
/* Install the job */
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
*pj = j;
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
j->installed = true;
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
tree-wide: make ++/-- usage consistent WRT spacing Throughout the tree there's spurious use of spaces separating ++ and -- operators from their respective operands. Make ++ and -- operator consistent with the majority of existing uses; discard the spaces.
2016-02-23 05:32:04 +01:00
j->manager->n_installed_jobs++;
core,network: major per-object logging rework This changes log_unit_info() (and friends) to take a real Unit* object insted of just a unit name as parameter. The call will now prefix all logged messages with the unit name, thus allowing the unit name to be dropped from the various passed romat strings, simplifying invocations drastically, and unifying log output across messages. Also, UNIT= vs. USER_UNIT= is now derived from the Manager object attached to the Unit object, instead of getpid(). This has the benefit of correcting the field for --test runs. Also contains a couple of other logging improvements: - Drops a couple of strerror() invocations in favour of using %m. - Not only .mount units now warn if a symlinks exist for the mount point already, .automount units do that too, now. - A few invocations of log_struct() that didn't actually pass any additional structured data have been replaced by simpler invocations of log_unit_info() and friends. - For structured data a new LOG_UNIT_MESSAGE() macro has been added, that works like LOG_MESSAGE() but prefixes the message with the unit name. Similar, there's now LOG_LINK_MESSAGE() and LOG_NETDEV_MESSAGE(). - For structured data new LOG_UNIT_ID(), LOG_LINK_INTERFACE(), LOG_NETDEV_INTERFACE() macros have been added that generate the necessary per object fields. The old log_unit_struct() call has been removed in favour of these new macros used in raw log_struct() invocations. In addition to removing one more function call this allows generated structured log messages that contain two object fields, as necessary for example for network interfaces that are joined into another network interface, and whose messages shall be indexed by both. - The LOG_ERRNO() macro has been removed, in favour of log_struct_errno(). The latter has the benefit of ensuring that %m in format strings is properly resolved to the specified error number. - A number of logging messages have been converted to use log_unit_info() instead of log_info() - The client code in sysv-generator no longer #includes core code from src/core/. - log_unit_full_errno() has been removed, log_unit_full() instead takes an errno now, too. - log_unit_info(), log_link_info(), log_netdev_info() and friends, now avoid double evaluation of their parameters
2015-05-11 20:38:21 +02:00
log_unit_debug(j->unit,
systemd: use unit logging macros
2013-01-05 18:00:35 +01:00
"Installed new job %s/%s as %u",
j->unit->id, job_type_to_string(j->type), (unsigned) j->id);
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
job_add_to_gc_queue(j);
core: when we install a job, announce this via the bus Whenever we enqueue a job, we should announce this on the bus, hence add both the job and the unit to the dbus queues. (Why both? The former should be obvious, the latter because we send out Job properties). In most cases adding these to the queue is not necessary, as other properties tend to change at the same time and result in a change being sent out. However, let's clean this up and make it explicit.
2018-11-29 18:48:32 +01:00
job_add_to_dbus_queue(j); /* announce this job to clients */
unit_add_to_dbus_queue(j->unit); /* The Job property of the unit has changed now */
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.
2012-04-20 09:38:43 +02:00
return j;
job: separate job_install() Let the jobs install themselves.
2012-04-20 02:04:01 +02:00
}
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
int job_install_deserialized(Job *j) {
Job **pj;
core: rework how we deserialize jobs Let's add a helper call unit_deserialize_job() for this purpose, and let's move registration in the global jobs hash table into job_install_deserialized() so that it it is done after all superficial checks are done, and before transitioning into installed states, so that rollback code is not necessary anymore.
2018-12-10 19:40:37 +01:00
int r;
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
assert(!j->installed);
coccinelle: make use of SYNTHETIC_ERRNO Ideally, coccinelle would strip unnecessary braces too. But I do not see any option in coccinelle for this, so instead, I edited the patch text using search&replace to remove the braces. Unfortunately this is not fully automatic, in particular it didn't deal well with if-else-if-else blocks and ifdefs, so there is an increased likelikehood be some bugs in such spots. I also removed part of the patch that coccinelle generated for udev, where we returns -1 for failure. This should be fixed independently.
2018-11-20 23:40:44 +01:00
if (j->type < 0 || j->type >= _JOB_TYPE_MAX_IN_TRANSACTION)
core: rework how we deserialize jobs Let's add a helper call unit_deserialize_job() for this purpose, and let's move registration in the global jobs hash table into job_install_deserialized() so that it it is done after all superficial checks are done, and before transitioning into installed states, so that rollback code is not necessary anymore.
2018-12-10 19:40:37 +01:00
return log_unit_debug_errno(j->unit, SYNTHETIC_ERRNO(EINVAL),
coccinelle: make use of SYNTHETIC_ERRNO Ideally, coccinelle would strip unnecessary braces too. But I do not see any option in coccinelle for this, so instead, I edited the patch text using search&replace to remove the braces. Unfortunately this is not fully automatic, in particular it didn't deal well with if-else-if-else blocks and ifdefs, so there is an increased likelikehood be some bugs in such spots. I also removed part of the patch that coccinelle generated for udev, where we returns -1 for failure. This should be fixed independently.
2018-11-20 23:40:44 +01:00
"Invalid job type %s in deserialization.",
strna(job_type_to_string(j->type)));
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
pj = (j->type == JOB_NOP) ? &j->unit->nop_job : &j->unit->job;
core: rework how we deserialize jobs Let's add a helper call unit_deserialize_job() for this purpose, and let's move registration in the global jobs hash table into job_install_deserialized() so that it it is done after all superficial checks are done, and before transitioning into installed states, so that rollback code is not necessary anymore.
2018-12-10 19:40:37 +01:00
if (*pj)
return log_unit_debug_errno(j->unit, SYNTHETIC_ERRNO(EEXIST),
"Unit already has a job installed. Not installing deserialized job.");
r = hashmap_put(j->manager->jobs, UINT32_TO_PTR(j->id), j);
if (r == -EEXIST)
return log_unit_debug_errno(j->unit, r, "Job ID %" PRIu32 " already used, cannot deserialize job.", j->id);
if (r < 0)
return log_unit_debug_errno(j->unit, r, "Failed to insert job into jobs hash table: %m");
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
*pj = j;
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
j->installed = true;
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
if (j->state == JOB_RUNNING)
j->unit->manager->n_running_jobs++;
core,network: major per-object logging rework This changes log_unit_info() (and friends) to take a real Unit* object insted of just a unit name as parameter. The call will now prefix all logged messages with the unit name, thus allowing the unit name to be dropped from the various passed romat strings, simplifying invocations drastically, and unifying log output across messages. Also, UNIT= vs. USER_UNIT= is now derived from the Manager object attached to the Unit object, instead of getpid(). This has the benefit of correcting the field for --test runs. Also contains a couple of other logging improvements: - Drops a couple of strerror() invocations in favour of using %m. - Not only .mount units now warn if a symlinks exist for the mount point already, .automount units do that too, now. - A few invocations of log_struct() that didn't actually pass any additional structured data have been replaced by simpler invocations of log_unit_info() and friends. - For structured data a new LOG_UNIT_MESSAGE() macro has been added, that works like LOG_MESSAGE() but prefixes the message with the unit name. Similar, there's now LOG_LINK_MESSAGE() and LOG_NETDEV_MESSAGE(). - For structured data new LOG_UNIT_ID(), LOG_LINK_INTERFACE(), LOG_NETDEV_INTERFACE() macros have been added that generate the necessary per object fields. The old log_unit_struct() call has been removed in favour of these new macros used in raw log_struct() invocations. In addition to removing one more function call this allows generated structured log messages that contain two object fields, as necessary for example for network interfaces that are joined into another network interface, and whose messages shall be indexed by both. - The LOG_ERRNO() macro has been removed, in favour of log_struct_errno(). The latter has the benefit of ensuring that %m in format strings is properly resolved to the specified error number. - A number of logging messages have been converted to use log_unit_info() instead of log_info() - The client code in sysv-generator no longer #includes core code from src/core/. - log_unit_full_errno() has been removed, log_unit_full() instead takes an errno now, too. - log_unit_info(), log_link_info(), log_netdev_info() and friends, now avoid double evaluation of their parameters
2015-05-11 20:38:21 +02:00
log_unit_debug(j->unit,
systemd: use unit logging macros
2013-01-05 18:00:35 +01:00
"Reinstalled deserialized job %s/%s as %u",
j->unit->id, job_type_to_string(j->type), (unsigned) j->id);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
return 0;
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
}
job: jobs shouldn't need to know about transaction anchors Let the transactions maintain their own anchor links.
2012-04-18 15:21:24 +02:00
JobDependency* job_dependency_new(Job *subject, Job *object, bool matters, bool conflicts) {
implement transaction engine
2010-01-20 02:12:51 +01:00
JobDependency *l;
assert(object);
/* Adds a new job link, which encodes that the 'subject' job
* needs the 'object' job in some way. If 'subject' is NULL
* this means the 'anchor' job (i.e. the one the user
Spelling Corrections Just some lame spelling corrections with no functionality.
2011-02-21 15:32:17 +01:00
* explicitly asked for) is the requester. */
implement transaction engine
2010-01-20 02:12:51 +01:00
core: a few small coding style/modernization updates for job.c
2016-11-15 19:19:57 +01:00
l = new0(JobDependency, 1);
if (!l)
implement transaction engine
2010-01-20 02:12:51 +01:00
return NULL;
l->subject = subject;
l->object = object;
l->matters = matters;
manager: when two pending jobs conflict, keep the one that "conflicts", remove the one that is "conflicted" This gives the writer of units control which unit is kept and which is stopped when two units conflict.
2010-08-09 22:32:30 +02:00
l->conflicts = conflicts;
implement transaction engine
2010-01-20 02:12:51 +01:00
various cleanups
2010-01-26 07:02:51 +01:00
if (subject)
list: make our list macros a bit easier to use by not requring type spec on each invocation We can determine the list entry type via the typeof() gcc construct, and so we should to make the macros much shorter to use.
2013-10-14 06:10:14 +02:00
LIST_PREPEND(subject, subject->subject_list, l);
implement transaction engine
2010-01-20 02:12:51 +01:00
list: make our list macros a bit easier to use by not requring type spec on each invocation We can determine the list entry type via the typeof() gcc construct, and so we should to make the macros much shorter to use.
2013-10-14 06:10:14 +02:00
LIST_PREPEND(object, object->object_list, l);
implement transaction engine
2010-01-20 02:12:51 +01:00
return l;
}
job: jobs shouldn't need to know about transaction anchors Let the transactions maintain their own anchor links.
2012-04-18 15:21:24 +02:00
void job_dependency_free(JobDependency *l) {
implement transaction engine
2010-01-20 02:12:51 +01:00
assert(l);
various cleanups
2010-01-26 07:02:51 +01:00
if (l->subject)
list: make our list macros a bit easier to use by not requring type spec on each invocation We can determine the list entry type via the typeof() gcc construct, and so we should to make the macros much shorter to use.
2013-10-14 06:10:14 +02:00
LIST_REMOVE(subject, l->subject->subject_list, l);
implement transaction engine
2010-01-20 02:12:51 +01:00
list: make our list macros a bit easier to use by not requring type spec on each invocation We can determine the list entry type via the typeof() gcc construct, and so we should to make the macros much shorter to use.
2013-10-14 06:10:14 +02:00
LIST_REMOVE(object, l->object->object_list, l);
implement transaction engine
2010-01-20 02:12:51 +01:00
free(l);
}
tree-wide: add whitespace between type and variable name
2018-12-04 09:29:54 +01:00
void job_dump(Job *j, FILE *f, const char *prefix) {
add functions for dumping server state
2010-01-19 00:22:34 +01:00
assert(j);
assert(f);
cocci: use strempty() at more places This shortens the code by a few lines.
2018-01-10 17:11:19 +01:00
prefix = strempty(prefix);
job: don't show (null) prefix in dump
2010-05-20 01:14:09 +02:00
improve dump output
2010-01-20 02:35:46 +01:00
fprintf(f,
get rid of unicode arrows, since the linux console cannot show them, not even in unicode mode
2010-04-23 20:25:55 +02:00
"%s-> Job %u:\n"
"%s\tAction: %s -> %s\n"
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
"%s\tState: %s\n"
pid1: also show gc status for jobs like we do for units
2018-02-14 00:52:21 +01:00
"%s\tIrreversible: %s\n"
"%s\tMay GC: %s\n",
improve dump output
2010-01-20 02:35:46 +01:00
prefix, j->id,
unit: remove union Unit Now that objects of all unit types are allocated the exact amount of memory they need, the Unit union has lost its purpose. Remove it. "Unit" is a more natural name for the base unit class than "Meta", so rename Meta to Unit. Access to members of the base class gets simplified.
2012-01-15 12:04:08 +01:00
prefix, j->unit->id, job_type_to_string(j->type),
greatly extend what we enforce as process properties
2010-01-30 01:55:42 +01:00
prefix, job_state_to_string(j->state),
pid1: also show gc status for jobs like we do for units
2018-02-14 00:52:21 +01:00
prefix, yes_no(j->irreversible),
prefix, yes_no(job_may_gc(j)));
add functions for dumping server state
2010-01-19 00:22:34 +01:00
}
implement transaction engine
2010-01-20 02:12:51 +01:00
job: use a lookup table for merging of job types It is easier to see what job_type_merge() is doing when the merging rules are written in the form of a table. job_type_is_superset() contained redundant information. It can be simplified to a simple rule: Type A is a superset of B iff merging A with B gives A. Two job types are conflicting iff they are not mergeable. Make job_type_lookup_merge() the core function to decide the type merging. All other job_type_*() are just short wrappers around it. They can be inline. test-job-type gives the same results as before. btw, the systemd binary is smaller by almost 1 KB.
2012-04-05 08:34:05 +02:00
/*
* Merging is commutative, so imagine the matrix as symmetric. We store only
* its lower triangle to avoid duplication. We don't store the main diagonal,
* because A merged with A is simply A.
*
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
* If the resulting type is collapsed immediately afterwards (to get rid of
* the JOB_RELOAD_OR_START, which lies outside the lookup function's domain),
* the following properties hold:
*
core: fix explanation of associativity
2015-03-11 14:53:16 +01:00
* Merging is associative! A merged with B, and then merged with C is the same
core: add missing words to my fix of explanation of associativity
2015-03-12 12:23:59 +01:00
* as A merged with the result of B merged with C.
job: use a lookup table for merging of job types It is easier to see what job_type_merge() is doing when the merging rules are written in the form of a table. job_type_is_superset() contained redundant information. It can be simplified to a simple rule: Type A is a superset of B iff merging A with B gives A. Two job types are conflicting iff they are not mergeable. Make job_type_lookup_merge() the core function to decide the type merging. All other job_type_*() are just short wrappers around it. They can be inline. test-job-type gives the same results as before. btw, the systemd binary is smaller by almost 1 KB.
2012-04-05 08:34:05 +02:00
*
* Mergeability is transitive! If A can be merged with B and B with C then
* A also with C.
*
* Also, if A merged with B cannot be merged with C, then either A or B cannot
* be merged with C either.
*/
static const JobType job_merging_table[] = {
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
/* What \ With * JOB_START JOB_VERIFY_ACTIVE JOB_STOP JOB_RELOAD */
/*********************************************************************************/
job: use a lookup table for merging of job types It is easier to see what job_type_merge() is doing when the merging rules are written in the form of a table. job_type_is_superset() contained redundant information. It can be simplified to a simple rule: Type A is a superset of B iff merging A with B gives A. Two job types are conflicting iff they are not mergeable. Make job_type_lookup_merge() the core function to decide the type merging. All other job_type_*() are just short wrappers around it. They can be inline. test-job-type gives the same results as before. btw, the systemd binary is smaller by almost 1 KB.
2012-04-05 08:34:05 +02:00
/*JOB_START */
/*JOB_VERIFY_ACTIVE */ JOB_START,
/*JOB_STOP */ -1, -1,
/*JOB_RELOAD */ JOB_RELOAD_OR_START, JOB_RELOAD, -1,
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
/*JOB_RESTART */ JOB_RESTART, JOB_RESTART, -1, JOB_RESTART,
job: use a lookup table for merging of job types It is easier to see what job_type_merge() is doing when the merging rules are written in the form of a table. job_type_is_superset() contained redundant information. It can be simplified to a simple rule: Type A is a superset of B iff merging A with B gives A. Two job types are conflicting iff they are not mergeable. Make job_type_lookup_merge() the core function to decide the type merging. All other job_type_*() are just short wrappers around it. They can be inline. test-job-type gives the same results as before. btw, the systemd binary is smaller by almost 1 KB.
2012-04-05 08:34:05 +02:00
};
JobType job_type_lookup_merge(JobType a, JobType b) {
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
assert_cc(ELEMENTSOF(job_merging_table) == _JOB_TYPE_MAX_MERGING * (_JOB_TYPE_MAX_MERGING - 1) / 2);
assert(a >= 0 && a < _JOB_TYPE_MAX_MERGING);
assert(b >= 0 && b < _JOB_TYPE_MAX_MERGING);
fix job merging
2010-01-21 00:51:37 +01:00
if (a == b)
job: use a lookup table for merging of job types It is easier to see what job_type_merge() is doing when the merging rules are written in the form of a table. job_type_is_superset() contained redundant information. It can be simplified to a simple rule: Type A is a superset of B iff merging A with B gives A. Two job types are conflicting iff they are not mergeable. Make job_type_lookup_merge() the core function to decide the type merging. All other job_type_*() are just short wrappers around it. They can be inline. test-job-type gives the same results as before. btw, the systemd binary is smaller by almost 1 KB.
2012-04-05 08:34:05 +02:00
return a;
fix job merging
2010-01-21 00:51:37 +01:00
job: use a lookup table for merging of job types It is easier to see what job_type_merge() is doing when the merging rules are written in the form of a table. job_type_is_superset() contained redundant information. It can be simplified to a simple rule: Type A is a superset of B iff merging A with B gives A. Two job types are conflicting iff they are not mergeable. Make job_type_lookup_merge() the core function to decide the type merging. All other job_type_*() are just short wrappers around it. They can be inline. test-job-type gives the same results as before. btw, the systemd binary is smaller by almost 1 KB.
2012-04-05 08:34:05 +02:00
if (a < b) {
JobType tmp = a;
a = b;
b = tmp;
fix job merging
2010-01-21 00:51:37 +01:00
}
make sure impact of transactions is minimized
2010-01-21 02:59:12 +01:00
job: use a lookup table for merging of job types It is easier to see what job_type_merge() is doing when the merging rules are written in the form of a table. job_type_is_superset() contained redundant information. It can be simplified to a simple rule: Type A is a superset of B iff merging A with B gives A. Two job types are conflicting iff they are not mergeable. Make job_type_lookup_merge() the core function to decide the type merging. All other job_type_*() are just short wrappers around it. They can be inline. test-job-type gives the same results as before. btw, the systemd binary is smaller by almost 1 KB.
2012-04-05 08:34:05 +02:00
return job_merging_table[(a - 1) * a / 2 + b];
make sure impact of transactions is minimized
2010-01-21 02:59:12 +01:00
}
only accept valid job types for specific names
2010-01-21 03:26:34 +01:00
job: define job_type_is_redundant() to idenity unnecessary jobs
2010-04-06 02:39:16 +02:00
bool job_type_is_redundant(JobType a, UnitActiveState b) {
switch (a) {
case JOB_START:
tree-wide: use IN_SET where possible In addition to the changes from #6933 this handles cases that could be matched with the included cocci file.
2017-09-29 00:37:23 +02:00
return IN_SET(b, UNIT_ACTIVE, UNIT_RELOADING);
job: define job_type_is_redundant() to idenity unnecessary jobs
2010-04-06 02:39:16 +02:00
case JOB_STOP:
tree-wide: use IN_SET where possible In addition to the changes from #6933 this handles cases that could be matched with the included cocci file.
2017-09-29 00:37:23 +02:00
return IN_SET(b, UNIT_INACTIVE, UNIT_FAILED);
job: define job_type_is_redundant() to idenity unnecessary jobs
2010-04-06 02:39:16 +02:00
case JOB_VERIFY_ACTIVE:
tree-wide: use IN_SET where possible In addition to the changes from #6933 this handles cases that could be matched with the included cocci file.
2017-09-29 00:37:23 +02:00
return IN_SET(b, UNIT_ACTIVE, UNIT_RELOADING);
job: define job_type_is_redundant() to idenity unnecessary jobs
2010-04-06 02:39:16 +02:00
case JOB_RELOAD:
return
unit: shorten active state enums to make systemctl output nicer
2010-07-01 03:34:15 +02:00
b == UNIT_RELOADING;
job: define job_type_is_redundant() to idenity unnecessary jobs
2010-04-06 02:39:16 +02:00
case JOB_RESTART:
return
b == UNIT_ACTIVATING;
core: fix assertion failure in checking a transaction with a JOB_NOP Several functions called from transaction_activate() need to correctly handle the case where a JOB_NOP job is being checked against a unit's pending job. The assumption that JOB_NOP never merges with other job types was correct, but since the job_type_is_*() functions are implemented using the merge lookup, they need to special-case JOB_NOP to avoid hitting assertion failures.
2014-11-26 16:33:43 +01:00
case JOB_NOP:
return true;
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
default:
assert_not_reached("Invalid job type");
}
}
core: when propagating restart requests due to deps, downgrade restart to try-restart Previously, if a service A depended on a service B via Requires=, and A was not running and B restarted this would trigger a start of A as well, since the restart was propagated as restart independently of the state of A. This patch ensures that a restart of B would be propagated as a try-restart to A, thus not changing its state if it isn't up. http://lists.freedesktop.org/archives/systemd-devel/2015-May/032061.html
2015-05-19 18:13:22 +02:00
JobType job_type_collapse(JobType t, Unit *u) {
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
UnitActiveState s;
core: when propagating restart requests due to deps, downgrade restart to try-restart Previously, if a service A depended on a service B via Requires=, and A was not running and B restarted this would trigger a start of A as well, since the restart was propagated as restart independently of the state of A. This patch ensures that a restart of B would be propagated as a try-restart to A, thus not changing its state if it isn't up. http://lists.freedesktop.org/archives/systemd-devel/2015-May/032061.html
2015-05-19 18:13:22 +02:00
switch (t) {
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
job: define job_type_is_redundant() to idenity unnecessary jobs
2010-04-06 02:39:16 +02:00
case JOB_TRY_RESTART:
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
s = unit_active_state(u);
if (UNIT_IS_INACTIVE_OR_DEACTIVATING(s))
core: when propagating restart requests due to deps, downgrade restart to try-restart Previously, if a service A depended on a service B via Requires=, and A was not running and B restarted this would trigger a start of A as well, since the restart was propagated as restart independently of the state of A. This patch ensures that a restart of B would be propagated as a try-restart to A, thus not changing its state if it isn't up. http://lists.freedesktop.org/archives/systemd-devel/2015-May/032061.html
2015-05-19 18:13:22 +02:00
return JOB_NOP;
return JOB_RESTART;
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
core: make sure "systemctl reload-or-try-restart is actually a noop if a unit is not running This makes sure we follow the same basic logic for try-restart if we have a try-reload. Fixes #688
2016-01-28 18:48:42 +01:00
case JOB_TRY_RELOAD:
s = unit_active_state(u);
if (UNIT_IS_INACTIVE_OR_DEACTIVATING(s))
return JOB_NOP;
return JOB_RELOAD;
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
case JOB_RELOAD_OR_START:
s = unit_active_state(u);
if (UNIT_IS_INACTIVE_OR_DEACTIVATING(s))
core: when propagating restart requests due to deps, downgrade restart to try-restart Previously, if a service A depended on a service B via Requires=, and A was not running and B restarted this would trigger a start of A as well, since the restart was propagated as restart independently of the state of A. This patch ensures that a restart of B would be propagated as a try-restart to A, thus not changing its state if it isn't up. http://lists.freedesktop.org/archives/systemd-devel/2015-May/032061.html
2015-05-19 18:13:22 +02:00
return JOB_START;
return JOB_RELOAD;
job: define job_type_is_redundant() to idenity unnecessary jobs
2010-04-06 02:39:16 +02:00
default:
core: when propagating restart requests due to deps, downgrade restart to try-restart Previously, if a service A depended on a service B via Requires=, and A was not running and B restarted this would trigger a start of A as well, since the restart was propagated as restart independently of the state of A. This patch ensures that a restart of B would be propagated as a try-restart to A, thus not changing its state if it isn't up. http://lists.freedesktop.org/archives/systemd-devel/2015-May/032061.html
2015-05-19 18:13:22 +02:00
return t;
job: define job_type_is_redundant() to idenity unnecessary jobs
2010-04-06 02:39:16 +02:00
}
}
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
int job_type_merge_and_collapse(JobType *a, JobType b, Unit *u) {
core: when propagating restart requests due to deps, downgrade restart to try-restart Previously, if a service A depended on a service B via Requires=, and A was not running and B restarted this would trigger a start of A as well, since the restart was propagated as restart independently of the state of A. This patch ensures that a restart of B would be propagated as a try-restart to A, thus not changing its state if it isn't up. http://lists.freedesktop.org/archives/systemd-devel/2015-May/032061.html
2015-05-19 18:13:22 +02:00
JobType t;
t = job_type_lookup_merge(*a, b);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
if (t < 0)
return -EEXIST;
core: when propagating restart requests due to deps, downgrade restart to try-restart Previously, if a service A depended on a service B via Requires=, and A was not running and B restarted this would trigger a start of A as well, since the restart was propagated as restart independently of the state of A. This patch ensures that a restart of B would be propagated as a try-restart to A, thus not changing its state if it isn't up. http://lists.freedesktop.org/archives/systemd-devel/2015-May/032061.html
2015-05-19 18:13:22 +02:00
*a = job_type_collapse(t, u);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
return 0;
}
Remove dead code and unexport some calls "make check-api-unused" informs us about code that is not used anymore or that is exported but only used internally. Fix these all over the place.
2013-11-08 18:11:09 +01:00
static bool job_is_runnable(Job *j) {
first attempt at proper service/socket logic
2010-01-26 04:18:44 +01:00
Iterator i;
s/name/unit
2010-01-26 21:39:06 +01:00
Unit *other;
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
void *v;
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
assert(j);
get rid of 'linked' notion for objects
2010-01-26 19:25:02 +01:00
assert(j->installed);
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
s/name/unit
2010-01-26 21:39:06 +01:00
/* Checks whether there is any job running for the units this
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
* job needs to be running after (in the case of a 'positive'
systemctl: introduce --ignore-dependencies
2011-02-16 21:59:31 +01:00
* job type) or before (in the case of a 'negative' job
* type. */
job: fix serialization
2013-11-22 19:14:11 +01:00
/* Note that unit types have a say in what is runnable,
* too. For example, if they return -EAGAIN from
* unit_start() they can indicate they are not
* runnable yet. */
systemctl: introduce --ignore-dependencies
2011-02-16 21:59:31 +01:00
/* First check if there is an override */
job: fix deserialization of jobs: do not ignore ordering
2011-04-06 19:09:33 +02:00
if (j->ignore_order)
systemctl: introduce --ignore-dependencies
2011-02-16 21:59:31 +01:00
return true;
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
if (j->type == JOB_NOP)
return true;
core: a few small coding style/modernization updates for job.c
2016-11-15 19:19:57 +01:00
if (IN_SET(j->type, JOB_START, JOB_VERIFY_ACTIVE, JOB_RELOAD)) {
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
/* Immediate result is that the job is or might be
treewide: fix typos of let's
2015-07-07 02:09:54 +02:00
* started. In this case let's wait for the
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
* dependencies, regardless whether they are
* starting or stopping something. */
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, j->unit->dependencies[UNIT_AFTER], i)
unit: remove union Unit Now that objects of all unit types are allocated the exact amount of memory they need, the Unit union has lost its purpose. Remove it. "Unit" is a more natural name for the base unit class than "Meta", so rename Meta to Unit. Access to members of the base class gets simplified.
2012-01-15 12:04:08 +01:00
if (other->job)
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
return false;
}
/* Also, if something else is being stopped and we should
treewide: fix typos of let's
2015-07-07 02:09:54 +02:00
* change state after it, then let's wait. */
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, j->unit->dependencies[UNIT_BEFORE], i)
unit: remove union Unit Now that objects of all unit types are allocated the exact amount of memory they need, the Unit union has lost its purpose. Remove it. "Unit" is a more natural name for the base unit class than "Meta", so rename Meta to Unit. Access to members of the base class gets simplified.
2012-01-15 12:04:08 +01:00
if (other->job &&
core: a few small coding style/modernization updates for job.c
2016-11-15 19:19:57 +01:00
IN_SET(other->job->type, JOB_STOP, JOB_RESTART))
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
return false;
/* This means that for a service a and a service b where b
* shall be started after a:
*
* start a + start b → 1st step start a, 2nd step start b
* start a + stop b → 1st step stop b, 2nd step start a
* stop a + start b → 1st step stop a, 2nd step start b
* stop a + stop b → 1st step stop b, 2nd step stop a
*
* This has the side effect that restarts are properly
* synchronized too. */
return true;
}
job: add debug prints where job type gets changed
2012-03-28 01:26:04 +02:00
static void job_change_type(Job *j, JobType newtype) {
core,network: major per-object logging rework This changes log_unit_info() (and friends) to take a real Unit* object insted of just a unit name as parameter. The call will now prefix all logged messages with the unit name, thus allowing the unit name to be dropped from the various passed romat strings, simplifying invocations drastically, and unifying log output across messages. Also, UNIT= vs. USER_UNIT= is now derived from the Manager object attached to the Unit object, instead of getpid(). This has the benefit of correcting the field for --test runs. Also contains a couple of other logging improvements: - Drops a couple of strerror() invocations in favour of using %m. - Not only .mount units now warn if a symlinks exist for the mount point already, .automount units do that too, now. - A few invocations of log_struct() that didn't actually pass any additional structured data have been replaced by simpler invocations of log_unit_info() and friends. - For structured data a new LOG_UNIT_MESSAGE() macro has been added, that works like LOG_MESSAGE() but prefixes the message with the unit name. Similar, there's now LOG_LINK_MESSAGE() and LOG_NETDEV_MESSAGE(). - For structured data new LOG_UNIT_ID(), LOG_LINK_INTERFACE(), LOG_NETDEV_INTERFACE() macros have been added that generate the necessary per object fields. The old log_unit_struct() call has been removed in favour of these new macros used in raw log_struct() invocations. In addition to removing one more function call this allows generated structured log messages that contain two object fields, as necessary for example for network interfaces that are joined into another network interface, and whose messages shall be indexed by both. - The LOG_ERRNO() macro has been removed, in favour of log_struct_errno(). The latter has the benefit of ensuring that %m in format strings is properly resolved to the specified error number. - A number of logging messages have been converted to use log_unit_info() instead of log_info() - The client code in sysv-generator no longer #includes core code from src/core/. - log_unit_full_errno() has been removed, log_unit_full() instead takes an errno now, too. - log_unit_info(), log_link_info(), log_netdev_info() and friends, now avoid double evaluation of their parameters
2015-05-11 20:38:21 +02:00
assert(j);
log_unit_debug(j->unit,
systemd: use unit logging macros
2013-01-05 18:00:35 +01:00
"Converting job %s/%s -> %s/%s",
j->unit->id, job_type_to_string(j->type),
j->unit->id, job_type_to_string(newtype));
job: add debug prints where job type gets changed
2012-03-28 01:26:04 +02:00
j->type = newtype;
}
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
_pure_ static const char* job_get_begin_status_message_format(Unit *u, JobType t) {
job: let's remove one comparison and reduce indentation level by one
2018-11-14 11:01:14 +01:00
const char *format;
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
assert(u);
job: let's remove one comparison and reduce indentation level by one
2018-11-14 11:01:14 +01:00
if (t == JOB_RELOAD)
return "Reloading %s.";
assert(IN_SET(t, JOB_START, JOB_STOP));
job: simplify status message extraction As @keszybz points out these fields are always here, there's no point in checking if they are NULL or not.
2018-11-16 15:28:26 +01:00
format = UNIT_VTABLE(u)->status_message_formats.starting_stopping[t == JOB_STOP];
if (format)
return format;
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
/* Return generic strings */
if (t == JOB_START)
return "Starting %s.";
job: let's remove one comparison and reduce indentation level by one
2018-11-14 11:01:14 +01:00
else {
assert(t == JOB_STOP);
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
return "Stopping %s.";
job: let's remove one comparison and reduce indentation level by one
2018-11-14 11:01:14 +01:00
}
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
}
static void job_print_begin_status_message(Unit *u, JobType t) {
const char *format;
assert(u);
/* Reload status messages have traditionally not been printed to console. */
if (!IN_SET(t, JOB_START, JOB_STOP))
return;
format = job_get_begin_status_message_format(u, t);
DISABLE_WARNING_FORMAT_NONLITERAL;
unit_status_printf(u, "", format);
REENABLE_WARNING;
}
job: also include job ID in log messages when we begin with a job
2018-11-13 20:16:45 +01:00
static void job_log_begin_status_message(Unit *u, uint32_t job_id, JobType t) {
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
const char *format, *mid;
char buf[LINE_MAX];
assert(u);
job: also include job ID in log messages when we begin with a job
2018-11-13 20:16:45 +01:00
assert(t >= 0);
assert(t < _JOB_TYPE_MAX);
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
if (!IN_SET(t, JOB_START, JOB_STOP, JOB_RELOAD))
return;
job: add two explanatory comments
2018-11-14 11:01:28 +01:00
if (log_on_console()) /* Skip this if it would only go on the console anyway */
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
return;
/* We log status messages for all units and all operations. */
format = job_get_begin_status_message_format(u, t);
DISABLE_WARNING_FORMAT_NONLITERAL;
Use unit->id instead of description in messages v2: - rename unit_identifier to unit_status_string
2019-06-06 17:33:59 +02:00
(void) snprintf(buf, sizeof buf, format, unit_status_string(u));
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
REENABLE_WARNING;
mid = t == JOB_START ? "MESSAGE_ID=" SD_MESSAGE_UNIT_STARTING_STR :
t == JOB_STOP ? "MESSAGE_ID=" SD_MESSAGE_UNIT_STOPPING_STR :
"MESSAGE_ID=" SD_MESSAGE_UNIT_RELOADING_STR;
/* Note that we deliberately use LOG_MESSAGE() instead of
* LOG_UNIT_MESSAGE() here, since this is supposed to mimic
* closely what is written to screen using the status output,
* which is supposed the highest level, friendliest output
* possible, which means we should avoid the low-level unit
* name. */
log_struct(LOG_INFO,
LOG_MESSAGE("%s", buf),
job: also include job ID in log messages when we begin with a job
2018-11-13 20:16:45 +01:00
"JOB_ID=%" PRIu32, job_id,
"JOB_TYPE=%s", job_type_to_string(t),
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
LOG_UNIT_ID(u),
LOG_UNIT_INVOCATION_ID(u),
mid);
}
job: also include job ID in log messages when we begin with a job
2018-11-13 20:16:45 +01:00
static void job_emit_begin_status_message(Unit *u, uint32_t job_id, JobType t) {
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
assert(u);
assert(t >= 0);
assert(t < _JOB_TYPE_MAX);
job: also include job ID in log messages when we begin with a job
2018-11-13 20:16:45 +01:00
job_log_begin_status_message(u, job_id, t);
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
job_print_begin_status_message(u, t);
}
core: fix confusing logging of instantaneous jobs For instantaneous jobs (e.g. starting of targets, sockets, slices, or Type=simple services) the log shows the job completion before starting: systemd[1]: Created slice -.slice. systemd[1]: Starting -.slice. systemd[1]: Created slice System Slice. systemd[1]: Starting System Slice. systemd[1]: Listening on Journal Audit Socket. systemd[1]: Starting Journal Audit Socket. systemd[1]: Reached target Timers. systemd[1]: Starting Timers. ... The reason is that the job completes before the ->start() method returns and only then does unit_start() print the "Starting ..." message. The same thing happens when stopping units. Rather than fixing the order of the messages, let's just not emit the Starting/Stopping message at all when the job completes instantaneously. The job completion message is sufficient in this case.
2015-07-16 20:08:30 +02:00
static int job_perform_on_unit(Job **j) {
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
uint32_t id;
Manager *m;
JobType t;
Unit *u;
core: fix confusing logging of instantaneous jobs For instantaneous jobs (e.g. starting of targets, sockets, slices, or Type=simple services) the log shows the job completion before starting: systemd[1]: Created slice -.slice. systemd[1]: Starting -.slice. systemd[1]: Created slice System Slice. systemd[1]: Starting System Slice. systemd[1]: Listening on Journal Audit Socket. systemd[1]: Starting Journal Audit Socket. systemd[1]: Reached target Timers. systemd[1]: Starting Timers. ... The reason is that the job completes before the ->start() method returns and only then does unit_start() print the "Starting ..." message. The same thing happens when stopping units. Rather than fixing the order of the messages, let's just not emit the Starting/Stopping message at all when the job completes instantaneously. The job completion message is sufficient in this case.
2015-07-16 20:08:30 +02:00
int r;
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
/* While we execute this operation the job might go away (for
* example: because it finishes immediately or is replaced by
* a new, conflicting job.) To make sure we don't access a
* freed job later on we store the id here, so that we can
* verify the job is still valid. */
assert(j);
assert(*j);
m = (*j)->manager;
u = (*j)->unit;
t = (*j)->type;
id = (*j)->id;
core: fix confusing logging of instantaneous jobs For instantaneous jobs (e.g. starting of targets, sockets, slices, or Type=simple services) the log shows the job completion before starting: systemd[1]: Created slice -.slice. systemd[1]: Starting -.slice. systemd[1]: Created slice System Slice. systemd[1]: Starting System Slice. systemd[1]: Listening on Journal Audit Socket. systemd[1]: Starting Journal Audit Socket. systemd[1]: Reached target Timers. systemd[1]: Starting Timers. ... The reason is that the job completes before the ->start() method returns and only then does unit_start() print the "Starting ..." message. The same thing happens when stopping units. Rather than fixing the order of the messages, let's just not emit the Starting/Stopping message at all when the job completes instantaneously. The job completion message is sufficient in this case.
2015-07-16 20:08:30 +02:00
switch (t) {
case JOB_START:
r = unit_start(u);
break;
case JOB_RESTART:
t = JOB_STOP;
tree-wide: adjust fall through comments so that gcc is happy Distcc removes comments, making the comment silencing not work. I know there was a decision against a macro in commit ec251fe7d5bc24b5d38b0853bc5969f3a0ba06e2
2017-11-19 19:06:10 +01:00
_fallthrough_;
core: fix confusing logging of instantaneous jobs For instantaneous jobs (e.g. starting of targets, sockets, slices, or Type=simple services) the log shows the job completion before starting: systemd[1]: Created slice -.slice. systemd[1]: Starting -.slice. systemd[1]: Created slice System Slice. systemd[1]: Starting System Slice. systemd[1]: Listening on Journal Audit Socket. systemd[1]: Starting Journal Audit Socket. systemd[1]: Reached target Timers. systemd[1]: Starting Timers. ... The reason is that the job completes before the ->start() method returns and only then does unit_start() print the "Starting ..." message. The same thing happens when stopping units. Rather than fixing the order of the messages, let's just not emit the Starting/Stopping message at all when the job completes instantaneously. The job completion message is sufficient in this case.
2015-07-16 20:08:30 +02:00
case JOB_STOP:
r = unit_stop(u);
break;
case JOB_RELOAD:
r = unit_reload(u);
break;
default:
assert_not_reached("Invalid job type");
}
job: add two explanatory comments
2018-11-14 11:01:28 +01:00
/* Log if the job still exists and the start/stop/reload function actually did something. Note that this means
* for units for which there's no 'activating' phase (i.e. because we transition directly from 'inactive' to
* 'active') we'll possibly skip the "Starting..." message. */
core: fix confusing logging of instantaneous jobs For instantaneous jobs (e.g. starting of targets, sockets, slices, or Type=simple services) the log shows the job completion before starting: systemd[1]: Created slice -.slice. systemd[1]: Starting -.slice. systemd[1]: Created slice System Slice. systemd[1]: Starting System Slice. systemd[1]: Listening on Journal Audit Socket. systemd[1]: Starting Journal Audit Socket. systemd[1]: Reached target Timers. systemd[1]: Starting Timers. ... The reason is that the job completes before the ->start() method returns and only then does unit_start() print the "Starting ..." message. The same thing happens when stopping units. Rather than fixing the order of the messages, let's just not emit the Starting/Stopping message at all when the job completes instantaneously. The job completion message is sufficient in this case.
2015-07-16 20:08:30 +02:00
*j = manager_get_job(m, id);
if (*j && r > 0)
job: also include job ID in log messages when we begin with a job
2018-11-13 20:16:45 +01:00
job_emit_begin_status_message(u, id, t);
core: fix confusing logging of instantaneous jobs For instantaneous jobs (e.g. starting of targets, sockets, slices, or Type=simple services) the log shows the job completion before starting: systemd[1]: Created slice -.slice. systemd[1]: Starting -.slice. systemd[1]: Created slice System Slice. systemd[1]: Starting System Slice. systemd[1]: Listening on Journal Audit Socket. systemd[1]: Starting Journal Audit Socket. systemd[1]: Reached target Timers. systemd[1]: Starting Timers. ... The reason is that the job completes before the ->start() method returns and only then does unit_start() print the "Starting ..." message. The same thing happens when stopping units. Rather than fixing the order of the messages, let's just not emit the Starting/Stopping message at all when the job completes instantaneously. The job completion message is sufficient in this case.
2015-07-16 20:08:30 +02:00
return r;
}
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
int job_run_and_invalidate(Job *j) {
int r;
get rid of 'linked' notion for objects
2010-01-26 19:25:02 +01:00
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
assert(j);
get rid of 'linked' notion for objects
2010-01-26 19:25:02 +01:00
assert(j->installed);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
assert(j->type < _JOB_TYPE_MAX_IN_TRANSACTION);
job: only jobs on the runqueue can be run
2012-05-12 21:06:27 +02:00
assert(j->in_run_queue);
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
list: make our list macros a bit easier to use by not requring type spec on each invocation We can determine the list entry type via the typeof() gcc construct, and so we should to make the macros much shorter to use.
2013-10-14 06:10:14 +02:00
LIST_REMOVE(run_queue, j->manager->run_queue, j);
job: only jobs on the runqueue can be run
2012-05-12 21:06:27 +02:00
j->in_run_queue = false;
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
if (j->state != JOB_WAITING)
return 0;
first attempt at proper service/socket logic
2010-01-26 04:18:44 +01:00
if (!job_is_runnable(j))
return -EAGAIN;
job: add JobRunningTimeoutSec for JOB_RUNNING state Unit.JobTimeoutSec starts when a job is enqueued in a transaction. The introduced distinct Unit.JobRunningTimeoutSec starts only when the job starts running (e.g. it groups all Exec* commands of a service or spans waiting for a device period.) Unit.JobRunningTimeoutSec is intended to be used by default instead of Unit.JobTimeoutSec for device units where such behavior causes less confusion (consider a job for a _netdev mount device, with this change the timeout will start ticking only after the network is ready).
2017-02-17 17:47:20 +01:00
job_start_timer(j, true);
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
job_set_state(j, JOB_RUNNING);
dbus: send out signals when units/jobs come, go and change
2010-02-05 00:38:41 +01:00
job_add_to_dbus_queue(j);
implement proper binding on ports
2010-01-23 22:56:47 +01:00
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
switch (j->type) {
case JOB_VERIFY_ACTIVE: {
job: minor coding style tweaks
2018-11-13 19:34:30 +01:00
UnitActiveState t;
t = unit_active_state(j->unit);
s/name/unit
2010-01-26 21:39:06 +01:00
if (UNIT_IS_ACTIVE_OR_RELOADING(t))
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
r = -EALREADY;
s/name/unit
2010-01-26 21:39:06 +01:00
else if (t == UNIT_ACTIVATING)
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
r = -EAGAIN;
else
systemd: treat reload failure as failure systemctl reload "suceeded" on stopped units, but it is documented to fail in this case. https://bugzilla.redhat.com/show_bug.cgi?id=1036845
2013-12-03 03:52:51 +01:00
r = -EBADR;
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
break;
}
core: fix confusing logging of instantaneous jobs For instantaneous jobs (e.g. starting of targets, sockets, slices, or Type=simple services) the log shows the job completion before starting: systemd[1]: Created slice -.slice. systemd[1]: Starting -.slice. systemd[1]: Created slice System Slice. systemd[1]: Starting System Slice. systemd[1]: Listening on Journal Audit Socket. systemd[1]: Starting Journal Audit Socket. systemd[1]: Reached target Timers. systemd[1]: Starting Timers. ... The reason is that the job completes before the ->start() method returns and only then does unit_start() print the "Starting ..." message. The same thing happens when stopping units. Rather than fixing the order of the messages, let's just not emit the Starting/Stopping message at all when the job completes instantaneously. The job completion message is sufficient in this case.
2015-07-16 20:08:30 +02:00
case JOB_START:
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
case JOB_STOP:
job: fix loss of ordering with restart jobs Suppose that foo.service/start is a job waiting on other job bar.service/start to finish. And then foo.service/restart is enqueued (not using --ignore-dependencies). Currently this makes foo.service start immediately, forgetting about the ordering to bar.service. The runnability check for JOB_RESTART jobs looks only at dependencies for stopping. That's actually correct, because restart jobs should be treated the same as stop jobs at first. The bug is that job_run_and_invalidate() does not treat them exactly the same as stop jobs. unit_start() gets called without checking for the runnability of the converted JOB_START job. The fix is to simplify the switch in job_run_and_invalidate(). Handle JOB_RESTART identically to JOB_STOP. Also simplify the handling of JOB_TRY_RESTART - just convert it to JOB_RESTART if the unit is active and let it fall through to the JOB_RESTART case. Similarly for JOB_RELOAD_OR_START - have a fall through to JOB_START. In job_finish_and_invalidate() it's not necessary to check for JOB_TRY_RESTART with JOB_DONE, because JOB_TRY_RESTART jobs will have been converted to JOB_RESTART already. Speeding up the restart of services in "auto-restart" state still works as before. Improves: https://bugzilla.redhat.com/show_bug.cgi?id=753586 but it's still not perfect. With this fix the try-restart action will wait for the restart to complete in the right order, but the optimal behaviour would be to finish quickly (without disturbing the start job).
2012-03-28 00:42:27 +02:00
case JOB_RESTART:
core: fix confusing logging of instantaneous jobs For instantaneous jobs (e.g. starting of targets, sockets, slices, or Type=simple services) the log shows the job completion before starting: systemd[1]: Created slice -.slice. systemd[1]: Starting -.slice. systemd[1]: Created slice System Slice. systemd[1]: Starting System Slice. systemd[1]: Listening on Journal Audit Socket. systemd[1]: Starting Journal Audit Socket. systemd[1]: Reached target Timers. systemd[1]: Starting Timers. ... The reason is that the job completes before the ->start() method returns and only then does unit_start() print the "Starting ..." message. The same thing happens when stopping units. Rather than fixing the order of the messages, let's just not emit the Starting/Stopping message at all when the job completes instantaneously. The job completion message is sufficient in this case.
2015-07-16 20:08:30 +02:00
r = job_perform_on_unit(&j);
job: make it possible to wait for devices to be unplugged
2010-11-14 21:57:10 +01:00
job: minor coding style tweaks
2018-11-13 19:34:30 +01:00
/* If the unit type does not support starting/stopping, then simply wait. */
job: make it possible to wait for devices to be unplugged
2010-11-14 21:57:10 +01:00
if (r == -EBADR)
r = 0;
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
break;
case JOB_RELOAD:
core: fix confusing logging of instantaneous jobs For instantaneous jobs (e.g. starting of targets, sockets, slices, or Type=simple services) the log shows the job completion before starting: systemd[1]: Created slice -.slice. systemd[1]: Starting -.slice. systemd[1]: Created slice System Slice. systemd[1]: Starting System Slice. systemd[1]: Listening on Journal Audit Socket. systemd[1]: Starting Journal Audit Socket. systemd[1]: Reached target Timers. systemd[1]: Starting Timers. ... The reason is that the job completes before the ->start() method returns and only then does unit_start() print the "Starting ..." message. The same thing happens when stopping units. Rather than fixing the order of the messages, let's just not emit the Starting/Stopping message at all when the job completes instantaneously. The job completion message is sufficient in this case.
2015-07-16 20:08:30 +02:00
r = job_perform_on_unit(&j);
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
break;
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
case JOB_NOP:
r = -EALREADY;
break;
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
default:
various cleanups
2010-01-26 07:02:51 +01:00
assert_not_reached("Unknown job type");
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
}
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
if (j) {
job: add comment for EAGAIN job run case
2018-11-13 19:39:04 +01:00
if (r == -EAGAIN)
job_set_state(j, JOB_WAITING); /* Hmm, not ready after all, let's return to JOB_WAITING state */
core: make unit_start() return a distinguishable error code in case conditions didn't hold Ideally we'd even propagate this all the way to the client, by having a separate JobType enum value for this. But it's hard to add this without breaking compat, hence for now let's at least internally propagate this case differently from the case "already on it". This is then used to call job_finish_and_invalidate() slightly differently, with the already= parameter false, as in the failed condition case no message was likely produced so far.
2018-11-14 11:38:51 +01:00
else if (r == -EALREADY) /* already being executed */
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
r = job_finish_and_invalidate(j, JOB_DONE, true, true);
core: make unit_start() return a distinguishable error code in case conditions didn't hold Ideally we'd even propagate this all the way to the client, by having a separate JobType enum value for this. But it's hard to add this without breaking compat, hence for now let's at least internally propagate this case differently from the case "already on it". This is then used to call job_finish_and_invalidate() slightly differently, with the already= parameter false, as in the failed condition case no message was likely produced so far.
2018-11-14 11:38:51 +01:00
else if (r == -ECOMM) /* condition failed, but all is good */
r = job_finish_and_invalidate(j, JOB_DONE, true, false);
systemd: treat reload failure as failure systemctl reload "suceeded" on stopped units, but it is documented to fail in this case. https://bugzilla.redhat.com/show_bug.cgi?id=1036845
2013-12-03 03:52:51 +01:00
else if (r == -EBADR)
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
r = job_finish_and_invalidate(j, JOB_SKIPPED, true, false);
systemd: treat reload failure as failure systemctl reload "suceeded" on stopped units, but it is documented to fail in this case. https://bugzilla.redhat.com/show_bug.cgi?id=1036845
2013-12-03 03:52:51 +01:00
else if (r == -ENOEXEC)
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
r = job_finish_and_invalidate(j, JOB_INVALID, true, false);
core: introduce the concept of AssertXYZ= similar to ConditionXYZ=, but fatal for a start job if not met
2014-11-06 13:43:45 +01:00
else if (r == -EPROTO)
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
r = job_finish_and_invalidate(j, JOB_ASSERT, true, false);
tree-wide: there is no ENOTSUP on linux Replace ENOTSUP by EOPNOTSUPP as this is what linux actually uses.
2015-03-13 14:08:00 +01:00
else if (r == -EOPNOTSUPP)
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
r = job_finish_and_invalidate(j, JOB_UNSUPPORTED, true, false);
core: explicitly verify that BindsTo= deps are in order before dispatch start operation of a unit Let's make sure we verify that all BindsTo= are in order before we actually go and dispatch a start operation to a unit. Normally the job queue should already have made sure all deps are in order, but this might not have been sufficient in two cases: a) when the user changes deps during runtime and reloads the daemon, and b) when the user placed BindsTo= dependencies without matching After= dependencies, so that we don't actually wait for the bound to unit to be up before upping also the binding unit. See: #4725
2016-11-24 18:47:48 +01:00
else if (r == -ENOLINK)
r = job_finish_and_invalidate(j, JOB_DEPENDENCY, true, false);
core: enforce that scope units can be started only once Scope units are populated from PIDs specified by the bus client. We do that when a scope is started. We really shouldn't allow scopes to be started multiple times, as the PIDs then might be heavily out of date. Moreover, clients should have the guarantee that any scope they allocate has a clear runtime cycle which is not repetitive.
2018-04-27 20:35:10 +02:00
else if (r == -ESTALE)
r = job_finish_and_invalidate(j, JOB_ONCE, true, false);
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
else if (r < 0)
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
r = job_finish_and_invalidate(j, JOB_FAILED, true, false);
job: don't accidently access a job that doesn't exist anymore
2010-08-13 19:29:21 +02:00
}
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
return r;
}
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
_pure_ static const char *job_get_done_status_message_format(Unit *u, JobType t, JobResult result) {
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
static const char *const generic_finished_start_job[_JOB_RESULT_MAX] = {
[JOB_DONE] = "Started %s.",
[JOB_TIMEOUT] = "Timed out starting %s.",
[JOB_FAILED] = "Failed to start %s.",
[JOB_DEPENDENCY] = "Dependency failed for %s.",
[JOB_ASSERT] = "Assertion failed for %s.",
[JOB_UNSUPPORTED] = "Starting of %s not supported.",
core: fix typo
2016-12-15 16:00:28 +01:00
[JOB_COLLECTED] = "Unnecessary job for %s was removed.",
core: enforce that scope units can be started only once Scope units are populated from PIDs specified by the bus client. We do that when a scope is started. We really shouldn't allow scopes to be started multiple times, as the PIDs then might be heavily out of date. Moreover, clients should have the guarantee that any scope they allocate has a clear runtime cycle which is not repetitive.
2018-04-27 20:35:10 +02:00
[JOB_ONCE] = "Unit %s has been started before and cannot be started again."
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
};
static const char *const generic_finished_stop_job[_JOB_RESULT_MAX] = {
[JOB_DONE] = "Stopped %s.",
[JOB_FAILED] = "Stopped (with error) %s.",
core: fix "stoppping" typo
2016-03-23 08:46:39 +01:00
[JOB_TIMEOUT] = "Timed out stopping %s.",
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
};
static const char *const generic_finished_reload_job[_JOB_RESULT_MAX] = {
[JOB_DONE] = "Reloaded %s.",
[JOB_FAILED] = "Reload failed for %s.",
[JOB_TIMEOUT] = "Timed out reloading %s.",
};
/* When verify-active detects the unit is inactive, report it.
* Most likely a DEPEND warning from a requisiting unit will
* occur next and it's nice to see what was requisited. */
static const char *const generic_finished_verify_active_job[_JOB_RESULT_MAX] = {
[JOB_SKIPPED] = "%s is not active.",
};
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
const char *format;
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
assert(u);
assert(t >= 0);
assert(t < _JOB_TYPE_MAX);
unit: unit type dependent status messages Instead of generic "Starting..." and "Started" messages for all unit use type-dependent messages. For example, mounts will announce "Mounting..." and "Mounted". Add status messages to units of types that used to be entirely silent (automounts, sockets, targets, devices). For unit types whose jobs are instantaneous, report only the job completion, not the starting event. Socket units with non-instantaneous jobs are rare (Exec*= is not used often in socket units), so I chose not to print the starting messages for them either. This will hopefully give people better understanding of the boot.
2012-05-13 18:18:54 +02:00
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
if (IN_SET(t, JOB_START, JOB_STOP, JOB_RESTART)) {
job: simplify status message extraction As @keszybz points out these fields are always here, there's no point in checking if they are NULL or not.
2018-11-16 15:28:26 +01:00
format = t == JOB_START ?
UNIT_VTABLE(u)->status_message_formats.finished_start_job[result] :
UNIT_VTABLE(u)->status_message_formats.finished_stop_job[result];
if (format)
return format;
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
}
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
/* Return generic strings */
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
if (t == JOB_START)
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
return generic_finished_start_job[result];
tree-wide: use IN_SET macro (#6977)
2017-10-04 16:01:32 +02:00
else if (IN_SET(t, JOB_STOP, JOB_RESTART))
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
return generic_finished_stop_job[result];
else if (t == JOB_RELOAD)
return generic_finished_reload_job[result];
else if (t == JOB_VERIFY_ACTIVE)
return generic_finished_verify_active_job[result];
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
return NULL;
}
core: do not print color console message about gc-ed jobs This is just a cosmetic issue. Garbage collection of jobs (especially the ones that we create automatically) is something of an internal implementation detail and should not be made visible to the users. But it's probably still useful to log this in the journal, so the code is rearranged to skip one of the messages if we log to the console and the journal separately, and to keep the message if we log everything to the console. Fixes #6254.
2017-07-02 01:05:36 +02:00
static const struct {
const char *color, *word;
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
} job_print_done_status_messages[_JOB_RESULT_MAX] = {
Add build-time option to change the color of the "OK" status text
2018-03-01 13:12:02 +01:00
[JOB_DONE] = { ANSI_OK_COLOR, " OK " },
core: do not print color console message about gc-ed jobs This is just a cosmetic issue. Garbage collection of jobs (especially the ones that we create automatically) is something of an internal implementation detail and should not be made visible to the users. But it's probably still useful to log this in the journal, so the code is rearranged to skip one of the messages if we log to the console and the journal separately, and to keep the message if we log everything to the console. Fixes #6254.
2017-07-02 01:05:36 +02:00
[JOB_TIMEOUT] = { ANSI_HIGHLIGHT_RED, " TIME " },
[JOB_FAILED] = { ANSI_HIGHLIGHT_RED, "FAILED" },
[JOB_DEPENDENCY] = { ANSI_HIGHLIGHT_YELLOW, "DEPEND" },
[JOB_SKIPPED] = { ANSI_HIGHLIGHT, " INFO " },
[JOB_ASSERT] = { ANSI_HIGHLIGHT_YELLOW, "ASSERT" },
[JOB_UNSUPPORTED] = { ANSI_HIGHLIGHT_YELLOW, "UNSUPP" },
/* JOB_COLLECTED */
core: enforce that scope units can be started only once Scope units are populated from PIDs specified by the bus client. We do that when a scope is started. We really shouldn't allow scopes to be started multiple times, as the PIDs then might be heavily out of date. Moreover, clients should have the guarantee that any scope they allocate has a clear runtime cycle which is not repetitive.
2018-04-27 20:35:10 +02:00
[JOB_ONCE] = { ANSI_HIGHLIGHT_RED, " ONCE " },
core: do not print color console message about gc-ed jobs This is just a cosmetic issue. Garbage collection of jobs (especially the ones that we create automatically) is something of an internal implementation detail and should not be made visible to the users. But it's probably still useful to log this in the journal, so the code is rearranged to skip one of the messages if we log to the console and the journal separately, and to keep the message if we log everything to the console. Fixes #6254.
2017-07-02 01:05:36 +02:00
};
job: also print status messages when we successfully started a unit
2011-04-16 03:07:38 +02:00
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
static void job_print_done_status_message(Unit *u, JobType t, JobResult result) {
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
const char *format;
systemd: obey systemd.log_color config Fixes #2845.
2016-03-16 14:27:37 +01:00
const char *status;
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
assert(u);
assert(t >= 0);
assert(t < _JOB_TYPE_MAX);
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
/* Reload status messages have traditionally not been printed to console. */
if (t == JOB_RELOAD)
return;
job: when a job was skipped due to a failed condition, log about it Previously we'd neither show console status output nor log output. Let's fix that, and still log something.
2018-11-14 11:08:16 +01:00
/* No message if the job did not actually do anything due to failed condition. */
if (t == JOB_START && result == JOB_DONE && !u->condition_result)
return;
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
if (!job_print_done_status_messages[result].word)
core: do not print color console message about gc-ed jobs This is just a cosmetic issue. Garbage collection of jobs (especially the ones that we create automatically) is something of an internal implementation detail and should not be made visible to the users. But it's probably still useful to log this in the journal, so the code is rearranged to skip one of the messages if we log to the console and the journal separately, and to keep the message if we log everything to the console. Fixes #6254.
2017-07-02 01:05:36 +02:00
return;
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
format = job_get_done_status_message_format(u, t, result);
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
if (!format)
return;
job: also print status messages when we successfully started a unit
2011-04-16 03:07:38 +02:00
systemd: obey systemd.log_color config Fixes #2845.
2016-03-16 14:27:37 +01:00
if (log_get_show_color())
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
status = strjoina(job_print_done_status_messages[result].color,
job_print_done_status_messages[result].word,
core: do not print color console message about gc-ed jobs This is just a cosmetic issue. Garbage collection of jobs (especially the ones that we create automatically) is something of an internal implementation detail and should not be made visible to the users. But it's probably still useful to log this in the journal, so the code is rearranged to skip one of the messages if we log to the console and the journal separately, and to keep the message if we log everything to the console. Fixes #6254.
2017-07-02 01:05:36 +02:00
ANSI_NORMAL);
systemd: obey systemd.log_color config Fixes #2845.
2016-03-16 14:27:37 +01:00
else
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
status = job_print_done_status_messages[result].word;
systemd: obey systemd.log_color config Fixes #2845.
2016-03-16 14:27:37 +01:00
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
if (result != JOB_DONE)
manager_flip_auto_status(u->manager, true);
job: also print status messages when we successfully started a unit
2011-04-16 03:07:38 +02:00
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
DISABLE_WARNING_FORMAT_NONLITERAL;
systemd: obey systemd.log_color config Fixes #2845.
2016-03-16 14:27:37 +01:00
unit_status_printf(u, status, format);
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
REENABLE_WARNING;
job: info message if JOB_VERIFY_ACTIVE detects an inactive unit
2012-05-13 23:29:19 +02:00
core: try harder to get job completion messages too This is similar to "core: always try harder to get unit status message format string", but for job completion status messages. It makes generic status messages applicable for printing to the console. And it rewrites the functions in a more table-based style.
2015-07-21 14:54:24 +02:00
if (t == JOB_START && result == JOB_FAILED) {
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
_cleanup_free_ char *quoted;
job: info message if JOB_VERIFY_ACTIVE detects an inactive unit
2012-05-13 23:29:19 +02:00
Use "dollar-single-quotes" to escape shell-sensitive strings Also called "ANSI-C Quoting" in info:(bash) ANSI-C Quoting. The escaping rules are a POSIX proposal, and are described in http://austingroupbugs.net/view.php?id=249. There's a lot of back-and-forth on the details of escaping of control characters, but we'll be only using a small subset of the syntax that is common to all proposals and is widely supported. Unfortunately dash and fish and maybe some other shells do not support it (see the man page patch for a list). This allows environment variables to be safely exported using show-environment and imported into the shell. Shells which do not support this syntax will have to do something like export $(systemctl show-environment|grep -v '=\$') or whatever is appropriate in their case. I think csh and fish do not support the A=B syntax anyway, so the change is moot for them. Fixes #5536. v2: - also escape newlines (which currently disallowed in shell values, so this doesn't really matter), and tabs (as $'\t'), and ! (as $'!'). This way quoted output can be included directly in both interactive and noninteractive bash.
2017-06-11 21:24:07 +02:00
quoted = shell_maybe_quote(u->id, ESCAPE_BACKSLASH);
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
manager_status_printf(u->manager, STATUS_TYPE_NORMAL, NULL, "See 'systemctl status %s' for details.", strna(quoted));
job: also print status messages when we successfully started a unit
2011-04-16 03:07:38 +02:00
}
}
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
static void job_log_done_status_message(Unit *u, uint32_t job_id, JobType t, JobResult result) {
tree-wide: add SD_ID128_MAKE_STR, remove LOG_MESSAGE_ID Embedding sd_id128_t's in constant strings was rather cumbersome. We had SD_ID128_CONST_STR which returned a const char[], but it had two problems: - it wasn't possible to statically concatanate this array with a normal string - gcc wasn't really able to optimize this, and generated code to perform the "conversion" at runtime. Because of this, even our own code in coredumpctl wasn't using SD_ID128_CONST_STR. Add a new macro to generate a constant string: SD_ID128_MAKE_STR. It is not as elegant as SD_ID128_CONST_STR, because it requires a repetition of the numbers, but in practice it is more convenient to use, and allows gcc to generate smarter code: $ size .libs/systemd{,-logind,-journald}{.old,} text data bss dec hex filename 1265204 149564 4808 1419576 15a938 .libs/systemd.old 1260268 149564 4808 1414640 1595f0 .libs/systemd 246805 13852 209 260866 3fb02 .libs/systemd-logind.old 240973 13852 209 255034 3e43a .libs/systemd-logind 146839 4984 34 151857 25131 .libs/systemd-journald.old 146391 4984 34 151409 24f71 .libs/systemd-journald It is also much easier to check if a certain binary uses a certain MESSAGE_ID: $ strings .libs/systemd.old|grep MESSAGE_ID MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x $ strings .libs/systemd|grep MESSAGE_ID MESSAGE_ID=c7a787079b354eaaa9e77b371893cd27 MESSAGE_ID=b07a249cd024414a82dd00cd181378ff MESSAGE_ID=641257651c1b4ec9a8624d7a40a9e1e7 MESSAGE_ID=de5b426a63be47a7b6ac3eaac82e2f6f MESSAGE_ID=d34d037fff1847e6ae669a370e694725 MESSAGE_ID=7d4958e842da4a758f6c1cdc7b36dcc5 MESSAGE_ID=1dee0369c7fc4736b7099b38ecb46ee7 MESSAGE_ID=39f53479d3a045ac8e11786248231fbf MESSAGE_ID=be02cf6855d2428ba40df7e9d022f03d MESSAGE_ID=7b05ebc668384222baa8881179cfda54 MESSAGE_ID=9d1aaa27d60140bd96365438aad20286
2016-11-06 18:48:23 +01:00
const char *format, *mid;
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
char buf[LINE_MAX];
core: adjust job completion message log levels We do not print all non-OK job completion status messages to the console in red, because not all of them are plain errors. We do however log the same messages as LOG_ERR. Differentiate the log levels by deducing them from the job result in a way that more or less matches the color of the console message.
2015-07-21 19:07:24 +02:00
static const int job_result_log_level[_JOB_RESULT_MAX] = {
[JOB_DONE] = LOG_INFO,
[JOB_CANCELED] = LOG_INFO,
[JOB_TIMEOUT] = LOG_ERR,
[JOB_FAILED] = LOG_ERR,
[JOB_DEPENDENCY] = LOG_WARNING,
[JOB_SKIPPED] = LOG_NOTICE,
[JOB_INVALID] = LOG_INFO,
[JOB_ASSERT] = LOG_WARNING,
[JOB_UNSUPPORTED] = LOG_WARNING,
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
[JOB_COLLECTED] = LOG_INFO,
core: enforce that scope units can be started only once Scope units are populated from PIDs specified by the bus client. We do that when a scope is started. We really shouldn't allow scopes to be started multiple times, as the PIDs then might be heavily out of date. Moreover, clients should have the guarantee that any scope they allocate has a clear runtime cycle which is not repetitive.
2018-04-27 20:35:10 +02:00
[JOB_ONCE] = LOG_ERR,
core: adjust job completion message log levels We do not print all non-OK job completion status messages to the console in red, because not all of them are plain errors. We do however log the same messages as LOG_ERR. Differentiate the log levels by deducing them from the job result in a way that more or less matches the color of the console message.
2015-07-21 19:07:24 +02:00
};
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
assert(u);
assert(t >= 0);
assert(t < _JOB_TYPE_MAX);
core: do not print color console message about gc-ed jobs This is just a cosmetic issue. Garbage collection of jobs (especially the ones that we create automatically) is something of an internal implementation detail and should not be made visible to the users. But it's probably still useful to log this in the journal, so the code is rearranged to skip one of the messages if we log to the console and the journal separately, and to keep the message if we log everything to the console. Fixes #6254.
2017-07-02 01:05:36 +02:00
/* Skip printing if output goes to the console, and job_print_status_message()
will actually print something to the console. */
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
if (log_on_console() && job_print_done_status_messages[result].word)
journal: suppress structured messages if they'd go to the console
2012-08-24 22:43:33 +02:00
return;
job: when a job was skipped due to a failed condition, log about it Previously we'd neither show console status output nor log output. Let's fix that, and still log something.
2018-11-14 11:08:16 +01:00
/* Show condition check message if the job did not actually do anything due to failed condition. */
if (t == JOB_START && result == JOB_DONE && !u->condition_result) {
log_struct(LOG_INFO,
Use unit->id instead of description in messages v2: - rename unit_identifier to unit_status_string
2019-06-06 17:33:59 +02:00
"MESSAGE=Condition check resulted in %s being skipped.", unit_status_string(u),
job: when a job was skipped due to a failed condition, log about it Previously we'd neither show console status output nor log output. Let's fix that, and still log something.
2018-11-14 11:08:16 +01:00
"JOB_ID=%" PRIu32, job_id,
"JOB_TYPE=%s", job_type_to_string(t),
"JOB_RESULT=%s", job_result_to_string(result),
LOG_UNIT_ID(u),
LOG_UNIT_INVOCATION_ID(u),
"MESSAGE_ID=" SD_MESSAGE_UNIT_STARTED_STR);
return;
}
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
format = job_get_done_status_message_format(u, t, result);
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
if (!format)
return;
job: truncate unit description The comment above says we're truncating the string but that's not true, an assert will fail in xsprintf if the description is longer than LINE_MAX. Let's use snprintf instead of xsprintf to make sure it's truncated. We'll cast its result to void to tell static checkers we're fine with truncation.
2018-02-16 14:32:44 +01:00
/* The description might be longer than the buffer, but that's OK,
* we'll just truncate it here. Note that we use snprintf() rather than
* xsprintf() on purpose here: we are fine with truncation and don't
* consider that an error. */
macro: introduce a nice macro for disabling -Wformat-nonliteral temporarily
2014-02-20 18:18:32 +01:00
DISABLE_WARNING_FORMAT_NONLITERAL;
Use unit->id instead of description in messages v2: - rename unit_identifier to unit_status_string
2019-06-06 17:33:59 +02:00
(void) snprintf(buf, sizeof(buf), format, unit_status_string(u));
macro: introduce a nice macro for disabling -Wformat-nonliteral temporarily
2014-02-20 18:18:32 +01:00
REENABLE_WARNING;
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
switch (t) {
case JOB_START:
tree-wide: add SD_ID128_MAKE_STR, remove LOG_MESSAGE_ID Embedding sd_id128_t's in constant strings was rather cumbersome. We had SD_ID128_CONST_STR which returned a const char[], but it had two problems: - it wasn't possible to statically concatanate this array with a normal string - gcc wasn't really able to optimize this, and generated code to perform the "conversion" at runtime. Because of this, even our own code in coredumpctl wasn't using SD_ID128_CONST_STR. Add a new macro to generate a constant string: SD_ID128_MAKE_STR. It is not as elegant as SD_ID128_CONST_STR, because it requires a repetition of the numbers, but in practice it is more convenient to use, and allows gcc to generate smarter code: $ size .libs/systemd{,-logind,-journald}{.old,} text data bss dec hex filename 1265204 149564 4808 1419576 15a938 .libs/systemd.old 1260268 149564 4808 1414640 1595f0 .libs/systemd 246805 13852 209 260866 3fb02 .libs/systemd-logind.old 240973 13852 209 255034 3e43a .libs/systemd-logind 146839 4984 34 151857 25131 .libs/systemd-journald.old 146391 4984 34 151409 24f71 .libs/systemd-journald It is also much easier to check if a certain binary uses a certain MESSAGE_ID: $ strings .libs/systemd.old|grep MESSAGE_ID MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x $ strings .libs/systemd|grep MESSAGE_ID MESSAGE_ID=c7a787079b354eaaa9e77b371893cd27 MESSAGE_ID=b07a249cd024414a82dd00cd181378ff MESSAGE_ID=641257651c1b4ec9a8624d7a40a9e1e7 MESSAGE_ID=de5b426a63be47a7b6ac3eaac82e2f6f MESSAGE_ID=d34d037fff1847e6ae669a370e694725 MESSAGE_ID=7d4958e842da4a758f6c1cdc7b36dcc5 MESSAGE_ID=1dee0369c7fc4736b7099b38ecb46ee7 MESSAGE_ID=39f53479d3a045ac8e11786248231fbf MESSAGE_ID=be02cf6855d2428ba40df7e9d022f03d MESSAGE_ID=7b05ebc668384222baa8881179cfda54 MESSAGE_ID=9d1aaa27d60140bd96365438aad20286
2016-11-06 18:48:23 +01:00
if (result == JOB_DONE)
mid = "MESSAGE_ID=" SD_MESSAGE_UNIT_STARTED_STR;
else
mid = "MESSAGE_ID=" SD_MESSAGE_UNIT_FAILED_STR;
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
break;
case JOB_RELOAD:
tree-wide: add SD_ID128_MAKE_STR, remove LOG_MESSAGE_ID Embedding sd_id128_t's in constant strings was rather cumbersome. We had SD_ID128_CONST_STR which returned a const char[], but it had two problems: - it wasn't possible to statically concatanate this array with a normal string - gcc wasn't really able to optimize this, and generated code to perform the "conversion" at runtime. Because of this, even our own code in coredumpctl wasn't using SD_ID128_CONST_STR. Add a new macro to generate a constant string: SD_ID128_MAKE_STR. It is not as elegant as SD_ID128_CONST_STR, because it requires a repetition of the numbers, but in practice it is more convenient to use, and allows gcc to generate smarter code: $ size .libs/systemd{,-logind,-journald}{.old,} text data bss dec hex filename 1265204 149564 4808 1419576 15a938 .libs/systemd.old 1260268 149564 4808 1414640 1595f0 .libs/systemd 246805 13852 209 260866 3fb02 .libs/systemd-logind.old 240973 13852 209 255034 3e43a .libs/systemd-logind 146839 4984 34 151857 25131 .libs/systemd-journald.old 146391 4984 34 151409 24f71 .libs/systemd-journald It is also much easier to check if a certain binary uses a certain MESSAGE_ID: $ strings .libs/systemd.old|grep MESSAGE_ID MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x $ strings .libs/systemd|grep MESSAGE_ID MESSAGE_ID=c7a787079b354eaaa9e77b371893cd27 MESSAGE_ID=b07a249cd024414a82dd00cd181378ff MESSAGE_ID=641257651c1b4ec9a8624d7a40a9e1e7 MESSAGE_ID=de5b426a63be47a7b6ac3eaac82e2f6f MESSAGE_ID=d34d037fff1847e6ae669a370e694725 MESSAGE_ID=7d4958e842da4a758f6c1cdc7b36dcc5 MESSAGE_ID=1dee0369c7fc4736b7099b38ecb46ee7 MESSAGE_ID=39f53479d3a045ac8e11786248231fbf MESSAGE_ID=be02cf6855d2428ba40df7e9d022f03d MESSAGE_ID=7b05ebc668384222baa8881179cfda54 MESSAGE_ID=9d1aaa27d60140bd96365438aad20286
2016-11-06 18:48:23 +01:00
mid = "MESSAGE_ID=" SD_MESSAGE_UNIT_RELOADED_STR;
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
break;
case JOB_STOP:
case JOB_RESTART:
tree-wide: add SD_ID128_MAKE_STR, remove LOG_MESSAGE_ID Embedding sd_id128_t's in constant strings was rather cumbersome. We had SD_ID128_CONST_STR which returned a const char[], but it had two problems: - it wasn't possible to statically concatanate this array with a normal string - gcc wasn't really able to optimize this, and generated code to perform the "conversion" at runtime. Because of this, even our own code in coredumpctl wasn't using SD_ID128_CONST_STR. Add a new macro to generate a constant string: SD_ID128_MAKE_STR. It is not as elegant as SD_ID128_CONST_STR, because it requires a repetition of the numbers, but in practice it is more convenient to use, and allows gcc to generate smarter code: $ size .libs/systemd{,-logind,-journald}{.old,} text data bss dec hex filename 1265204 149564 4808 1419576 15a938 .libs/systemd.old 1260268 149564 4808 1414640 1595f0 .libs/systemd 246805 13852 209 260866 3fb02 .libs/systemd-logind.old 240973 13852 209 255034 3e43a .libs/systemd-logind 146839 4984 34 151857 25131 .libs/systemd-journald.old 146391 4984 34 151409 24f71 .libs/systemd-journald It is also much easier to check if a certain binary uses a certain MESSAGE_ID: $ strings .libs/systemd.old|grep MESSAGE_ID MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x $ strings .libs/systemd|grep MESSAGE_ID MESSAGE_ID=c7a787079b354eaaa9e77b371893cd27 MESSAGE_ID=b07a249cd024414a82dd00cd181378ff MESSAGE_ID=641257651c1b4ec9a8624d7a40a9e1e7 MESSAGE_ID=de5b426a63be47a7b6ac3eaac82e2f6f MESSAGE_ID=d34d037fff1847e6ae669a370e694725 MESSAGE_ID=7d4958e842da4a758f6c1cdc7b36dcc5 MESSAGE_ID=1dee0369c7fc4736b7099b38ecb46ee7 MESSAGE_ID=39f53479d3a045ac8e11786248231fbf MESSAGE_ID=be02cf6855d2428ba40df7e9d022f03d MESSAGE_ID=7b05ebc668384222baa8881179cfda54 MESSAGE_ID=9d1aaa27d60140bd96365438aad20286
2016-11-06 18:48:23 +01:00
mid = "MESSAGE_ID=" SD_MESSAGE_UNIT_STOPPED_STR;
core: Minor cleaning up of unit/log status and log logic We only reorder a few things and modernize some constructs. No functional changes. - Move some if checks from the caller to the callee of a few functions. - Use IN_SE() where we can - Move status printing functions together
2015-11-17 17:11:44 +01:00
break;
default:
core: adjust job completion message log levels We do not print all non-OK job completion status messages to the console in red, because not all of them are plain errors. We do however log the same messages as LOG_ERR. Differentiate the log levels by deducing them from the job result in a way that more or less matches the color of the console message.
2015-07-21 19:07:24 +02:00
log_struct(job_result_log_level[result],
core: log completion of remaining job types JOB_RESTART and failed JOB_VERIFY_ACTIVE completions were printed to console but not to the log.
2015-07-21 16:20:18 +02:00
LOG_MESSAGE("%s", buf),
job: include JOB_ID field in log message about jobs
2018-11-13 19:28:54 +01:00
"JOB_ID=%" PRIu32, job_id,
job: change result field for log message about job result RESULT= → JOB_RESULT= So, currently, some of the structured log messages we generated based on jobs carry the result in RESULT=, and others in JOB_RESULT=. Let's streamline this, as stick to JOB_RESULT= in one place. This is kind of an API break, but given that currently most software has to check both fields anyway, I think we can get away with it. Why unify on JOB_RESULT= rather than RESULT=? Well, we manage different types of result codes in systemd. Most importanlty besides job results there are also service results, and we should be explicit in what we mean here.
2017-09-20 18:29:08 +02:00
"JOB_TYPE=%s", job_type_to_string(t),
"JOB_RESULT=%s", job_result_to_string(result),
tree-wide: mark log_struct with _printf_ and fix fallout log_struct takes multiple format strings, each one followed by arguments. The _printf_ annotation is not sufficiently flexible to express this, but we can still annotate the first format string, though not its arguments (because their number is unknown). With the annotation, the places which specified the message id or similar as the first pattern cause a warning from -Wformat-nonliteral. This can be trivially fixed by putting the MESSAGE= first. This change will help find issues where a non-literal is erroneously used as the pattern.
2017-04-20 20:15:28 +02:00
LOG_UNIT_ID(u),
basic/log: add the log_struct terminator to macro This way all callers do not need to specify it. Exhaustively tested by running test-log under valgrind ;)
2018-06-04 12:59:22 +02:00
LOG_UNIT_INVOCATION_ID(u));
core: small refactor of job completion logging Joins three log_struct() calls into one.
2015-07-21 17:26:28 +02:00
return;
}
core: adjust job completion message log levels We do not print all non-OK job completion status messages to the console in red, because not all of them are plain errors. We do however log the same messages as LOG_ERR. Differentiate the log levels by deducing them from the job result in a way that more or less matches the color of the console message.
2015-07-21 19:07:24 +02:00
log_struct(job_result_log_level[result],
core: small refactor of job completion logging Joins three log_struct() calls into one.
2015-07-21 17:26:28 +02:00
LOG_MESSAGE("%s", buf),
job: include JOB_ID field in log message about jobs
2018-11-13 19:28:54 +01:00
"JOB_ID=%" PRIu32, job_id,
job: change result field for log message about job result RESULT= → JOB_RESULT= So, currently, some of the structured log messages we generated based on jobs carry the result in RESULT=, and others in JOB_RESULT=. Let's streamline this, as stick to JOB_RESULT= in one place. This is kind of an API break, but given that currently most software has to check both fields anyway, I think we can get away with it. Why unify on JOB_RESULT= rather than RESULT=? Well, we manage different types of result codes in systemd. Most importanlty besides job results there are also service results, and we should be explicit in what we mean here.
2017-09-20 18:29:08 +02:00
"JOB_TYPE=%s", job_type_to_string(t),
"JOB_RESULT=%s", job_result_to_string(result),
tree-wide: mark log_struct with _printf_ and fix fallout log_struct takes multiple format strings, each one followed by arguments. The _printf_ annotation is not sufficiently flexible to express this, but we can still annotate the first format string, though not its arguments (because their number is unknown). With the annotation, the places which specified the message id or similar as the first pattern cause a warning from -Wformat-nonliteral. This can be trivially fixed by putting the MESSAGE= first. This change will help find issues where a non-literal is erroneously used as the pattern.
2017-04-20 20:15:28 +02:00
LOG_UNIT_ID(u),
core: make sure to log invocation ID of units also when doing structured logging
2017-09-20 18:27:53 +02:00
LOG_UNIT_INVOCATION_ID(u),
basic/log: add the log_struct terminator to macro This way all callers do not need to specify it. Exhaustively tested by running test-log under valgrind ;)
2018-06-04 12:59:22 +02:00
mid);
journal: generate structured journal messages for a number of events
2012-08-24 22:21:20 +02:00
}
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
static void job_emit_done_status_message(Unit *u, uint32_t job_id, JobType t, JobResult result) {
job: change result field for log message about job result RESULT= → JOB_RESULT= So, currently, some of the structured log messages we generated based on jobs carry the result in RESULT=, and others in JOB_RESULT=. Let's streamline this, as stick to JOB_RESULT= in one place. This is kind of an API break, but given that currently most software has to check both fields anyway, I think we can get away with it. Why unify on JOB_RESULT= rather than RESULT=? Well, we manage different types of result codes in systemd. Most importanlty besides job results there are also service results, and we should be explicit in what we mean here.
2017-09-20 18:29:08 +02:00
assert(u);
core: do not log done failed-condition jobs as if unit started It is misleading to see "Started foo." in the log when the unit's condition was false.
2015-07-21 16:15:19 +02:00
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
job_log_done_status_message(u, job_id, t, result);
job_print_done_status_message(u, t, result);
core: do not log done failed-condition jobs as if unit started It is misleading to see "Started foo." in the log when the unit's condition was false.
2015-07-21 16:15:19 +02:00
}
core: introduce seperate reverse dependencies for Requires= and Requisite= This allows us to ensure that Requisite= dependencies never cause propagation between units, while Requires= dependencies might. http://lists.freedesktop.org/archives/systemd-devel/2015-May/031742.html
2015-05-19 01:24:28 +02:00
static void job_fail_dependencies(Unit *u, UnitDependency d) {
Unit *other;
Iterator i;
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
void *v;
core: introduce seperate reverse dependencies for Requires= and Requisite= This allows us to ensure that Requisite= dependencies never cause propagation between units, while Requires= dependencies might. http://lists.freedesktop.org/archives/systemd-devel/2015-May/031742.html
2015-05-19 01:24:28 +02:00
assert(u);
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, u->dependencies[d], i) {
core: introduce seperate reverse dependencies for Requires= and Requisite= This allows us to ensure that Requisite= dependencies never cause propagation between units, while Requires= dependencies might. http://lists.freedesktop.org/archives/systemd-devel/2015-May/031742.html
2015-05-19 01:24:28 +02:00
Job *j = other->job;
if (!j)
continue;
if (!IN_SET(j->type, JOB_START, JOB_VERIFY_ACTIVE))
continue;
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
job_finish_and_invalidate(j, JOB_DEPENDENCY, true, false);
core: introduce seperate reverse dependencies for Requires= and Requisite= This allows us to ensure that Requisite= dependencies never cause propagation between units, while Requires= dependencies might. http://lists.freedesktop.org/archives/systemd-devel/2015-May/031742.html
2015-05-19 01:24:28 +02:00
}
}
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
int job_finish_and_invalidate(Job *j, JobResult result, bool recursive, bool already) {
s/name/unit
2010-01-26 21:39:06 +01:00
Unit *u;
Unit *other;
gcc: make a couple of gcc warnings go away
2010-03-31 20:08:05 +02:00
JobType t;
first attempt at proper service/socket logic
2010-01-26 04:18:44 +01:00
Iterator i;
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
void *v;
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
assert(j);
get rid of 'linked' notion for objects
2010-01-26 19:25:02 +01:00
assert(j->installed);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
assert(j->type < _JOB_TYPE_MAX_IN_TRANSACTION);
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
unit: unit type dependent status messages Instead of generic "Starting..." and "Started" messages for all unit use type-dependent messages. For example, mounts will announce "Mounting..." and "Mounted". Add status messages to units of types that used to be entirely silent (automounts, sockets, targets, devices). For unit types whose jobs are instantaneous, report only the job completion, not the starting event. Socket units with non-instantaneous jobs are rare (Exec*= is not used often in socket units), so I chose not to print the starting messages for them either. This will hopefully give people better understanding of the boot.
2012-05-13 18:18:54 +02:00
u = j->unit;
t = j->type;
j->result = result;
job: include JOB_ID field in log message about jobs
2018-11-13 19:28:54 +01:00
log_unit_debug(u, "Job %" PRIu32 " %s/%s finished, result=%s", j->id, u->id, job_type_to_string(t), job_result_to_string(result));
unit: unit type dependent status messages Instead of generic "Starting..." and "Started" messages for all unit use type-dependent messages. For example, mounts will announce "Mounting..." and "Mounted". Add status messages to units of types that used to be entirely silent (automounts, sockets, targets, devices). For unit types whose jobs are instantaneous, report only the job completion, not the starting event. Socket units with non-instantaneous jobs are rare (Exec*= is not used often in socket units), so I chose not to print the starting messages for them either. This will hopefully give people better understanding of the boot.
2012-05-13 18:18:54 +02:00
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
/* If this job did nothing to respective unit we don't log the status message */
if (!already)
core: move unit_status_emit_starting_stopping_reloading() and related calls to job.c This call is only used by job.c and very specific to job handling. Moreover the very similar logic of job_emit_status_message() is already in job.c. Hence, let's clean this up, and move both sets of functions to job.c, and rename them a bit so that they express precisely what they do: 1. unit_status_emit_starting_stopping_reloading() → job_emit_begin_status_message() 2. job_emit_status_message() → job_emit_done_status_message() The first call is after all what we call when we begin with the execution of a job, and the second call what we call when we are done wiht it. Just some moving and renaming, not other changes, and hence no change in behaviour.
2018-11-13 19:57:43 +01:00
job_emit_done_status_message(u, j->id, t, result);
unit: unit type dependent status messages Instead of generic "Starting..." and "Started" messages for all unit use type-dependent messages. For example, mounts will announce "Mounting..." and "Mounted". Add status messages to units of types that used to be entirely silent (automounts, sockets, targets, devices). For unit types whose jobs are instantaneous, report only the job completion, not the starting event. Socket units with non-instantaneous jobs are rare (Exec*= is not used often in socket units), so I chose not to print the starting messages for them either. This will hopefully give people better understanding of the boot.
2012-05-13 18:18:54 +02:00
first attempt at proper service/socket logic
2010-01-26 04:18:44 +01:00
/* Patch restart jobs so that they become normal start jobs */
unit: unit type dependent status messages Instead of generic "Starting..." and "Started" messages for all unit use type-dependent messages. For example, mounts will announce "Mounting..." and "Mounted". Add status messages to units of types that used to be entirely silent (automounts, sockets, targets, devices). For unit types whose jobs are instantaneous, report only the job completion, not the starting event. Socket units with non-instantaneous jobs are rare (Exec*= is not used often in socket units), so I chose not to print the starting messages for them either. This will hopefully give people better understanding of the boot.
2012-05-13 18:18:54 +02:00
if (result == JOB_DONE && t == JOB_RESTART) {
implement coldpluggin
2010-01-29 03:18:09 +01:00
job: add debug prints where job type gets changed
2012-03-28 01:26:04 +02:00
job_change_type(j, JOB_START);
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
job_set_state(j, JOB_WAITING);
job: make sure restart jobs are readded to the run queue after conversion to start jobs
2010-07-21 05:16:31 +02:00
core: simplify - don't add jobs to dbus queue if we immediately remove them (#7251) job_finish_and_invalidate() calls job_free() to destroy jobs (and remove them from the dbus queue). So we don't need to add them to the dbus queue first. We only want to add jobs to the dbus queue if they're a restart job, which we're transmogrifying into a start job and putting back into the system.
2017-11-07 17:14:15 +01:00
job_add_to_dbus_queue(j);
job: make sure restart jobs are readded to the run queue after conversion to start jobs
2010-07-21 05:16:31 +02:00
job_add_to_run_queue(j);
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
job_add_to_gc_queue(j);
job: after converting a job from restart to start readd it to run queue When we converted a restart job it's time to look again whether any of its dependencies are now runnable. https://bugzilla.redhat.com/show_bug.cgi?id=735013
2011-09-21 19:56:15 +02:00
goto finish;
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
}
tree-wide: use IN_SET where possible In addition to the changes from #6933 this handles cases that could be matched with the included cocci file.
2017-09-29 00:37:23 +02:00
if (IN_SET(result, JOB_FAILED, JOB_INVALID))
tree-wide: make ++/-- usage consistent WRT spacing Throughout the tree there's spurious use of spaces separating ++ and -- operators from their respective operands. Make ++ and -- operator consistent with the majority of existing uses; discard the spaces.
2016-02-23 05:32:04 +01:00
j->manager->n_failed_jobs++;
dbus: export number of total failed jobs on D-Bus interface
2010-09-23 15:38:42 +02:00
job: job_uninstall() 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.
2012-04-20 10:21:37 +02:00
job_uninstall(j);
core: don't track jobs-finishing-during-reload explicitly Memory management is borked for this, and moreover this is unnecessary since f0831ed2a03, i.e. since coldplug() and catchup() are two different concepts: the former restoring the state from before a reload, the latter than adjusting it again to the actual status in effect after the reload. Fixes: #10716 Mostly reverts: #8803
2018-12-10 18:52:28 +01:00
job_free(j);
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
/* Fail depending jobs on failure */
transaction: cancel jobs non-recursively on isolate 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
2012-04-24 11:21:03 +02:00
if (result != JOB_DONE && recursive) {
core: introduce seperate reverse dependencies for Requires= and Requisite= This allows us to ensure that Requisite= dependencies never cause propagation between units, while Requires= dependencies might. http://lists.freedesktop.org/archives/systemd-devel/2015-May/031742.html
2015-05-19 01:24:28 +02:00
if (IN_SET(t, JOB_START, JOB_VERIFY_ACTIVE)) {
job_fail_dependencies(u, UNIT_REQUIRED_BY);
job_fail_dependencies(u, UNIT_REQUISITE_OF);
job_fail_dependencies(u, UNIT_BOUND_BY);
} else if (t == JOB_STOP)
job_fail_dependencies(u, UNIT_CONFLICTED_BY);
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
}
Fail RequisiteOf units with oneshots Fixes: #11422 Oneshots going to inactive directly without ever entering UNIT_ACTIVE is considered success. This however means that if something both Requires= and Requisites= a unit of such nature, the verify-active job getting merged into the start job makes it lose this property of failing the depending jobs, as there, the start job has the result JOB_DONE on success, so we never walk over RequisiteOf units. This change makes sure that such units always go down. It is also only meaningful with After=, but so is Requisite= itself. Also, we also catch cases like a oneshot having RemainAfterExit= true making us start up properly in such a setting, but then removing it, reloading the unit, and restarting it. In such a case, we go down due to restart propagation before them, and our start job waits on theirs, properly failing with the JOB_DEPENDENCY result. This covers cases where ConditionXYZ= creates a similar situation as well.
2019-01-19 06:19:46 +01:00
/* A special check to make sure we take down anything RequisiteOf if we
* aren't active. This is when the verify-active job merges with a
* satisfying job type, and then loses it's invalidation effect, as the
* result there is JOB_DONE for the start job we merged into, while we
* should be failing the depending job if the said unit isn't infact
* active. Oneshots are an example of this, where going directly from
* activating to inactive is success.
*
* This happens when you use ConditionXYZ= in a unit too, since in that
* case the job completes with the JOB_DONE result, but the unit never
* really becomes active. Note that such a case still involves merging:
*
* A start job waits for something else, and a verify-active comes in
* and merges in the installed job. Then, later, when it becomes
* runnable, it finishes with JOB_DONE result as execution on conditions
* not being met is skipped, breaking our dependency semantics.
*
* Also, depending on if start job waits or not, the merging may or may
* not happen (the verify-active job may trigger after it finishes), so
* you get undeterministic results without this check.
*/
if (result == JOB_DONE && recursive && !UNIT_IS_ACTIVE_OR_RELOADING(unit_active_state(u))) {
if (IN_SET(t, JOB_START, JOB_RELOAD))
job_fail_dependencies(u, UNIT_REQUISITE_OF);
}
job: also trigger on-failure dependencies when jobs faile due to dependencies, timeout
2011-02-24 03:24:23 +01:00
/* Trigger OnFailure dependencies that are not generated by
systemd: use unit logging macros
2013-01-05 18:00:35 +01:00
* the unit itself. We don't treat JOB_CANCELED as failure in
job: also trigger on-failure dependencies when jobs faile due to dependencies, timeout
2011-02-24 03:24:23 +01:00
* this context. And JOB_FAILURE is already handled by the
* unit itself. */
job: change result field for log message about job result RESULT= → JOB_RESULT= So, currently, some of the structured log messages we generated based on jobs carry the result in RESULT=, and others in JOB_RESULT=. Let's streamline this, as stick to JOB_RESULT= in one place. This is kind of an API break, but given that currently most software has to check both fields anyway, I think we can get away with it. Why unify on JOB_RESULT= rather than RESULT=? Well, we manage different types of result codes in systemd. Most importanlty besides job results there are also service results, and we should be explicit in what we mean here.
2017-09-20 18:29:08 +02:00
if (IN_SET(result, JOB_TIMEOUT, JOB_DEPENDENCY)) {
core,network: major per-object logging rework This changes log_unit_info() (and friends) to take a real Unit* object insted of just a unit name as parameter. The call will now prefix all logged messages with the unit name, thus allowing the unit name to be dropped from the various passed romat strings, simplifying invocations drastically, and unifying log output across messages. Also, UNIT= vs. USER_UNIT= is now derived from the Manager object attached to the Unit object, instead of getpid(). This has the benefit of correcting the field for --test runs. Also contains a couple of other logging improvements: - Drops a couple of strerror() invocations in favour of using %m. - Not only .mount units now warn if a symlinks exist for the mount point already, .automount units do that too, now. - A few invocations of log_struct() that didn't actually pass any additional structured data have been replaced by simpler invocations of log_unit_info() and friends. - For structured data a new LOG_UNIT_MESSAGE() macro has been added, that works like LOG_MESSAGE() but prefixes the message with the unit name. Similar, there's now LOG_LINK_MESSAGE() and LOG_NETDEV_MESSAGE(). - For structured data new LOG_UNIT_ID(), LOG_LINK_INTERFACE(), LOG_NETDEV_INTERFACE() macros have been added that generate the necessary per object fields. The old log_unit_struct() call has been removed in favour of these new macros used in raw log_struct() invocations. In addition to removing one more function call this allows generated structured log messages that contain two object fields, as necessary for example for network interfaces that are joined into another network interface, and whose messages shall be indexed by both. - The LOG_ERRNO() macro has been removed, in favour of log_struct_errno(). The latter has the benefit of ensuring that %m in format strings is properly resolved to the specified error number. - A number of logging messages have been converted to use log_unit_info() instead of log_info() - The client code in sysv-generator no longer #includes core code from src/core/. - log_unit_full_errno() has been removed, log_unit_full() instead takes an errno now, too. - log_unit_info(), log_link_info(), log_netdev_info() and friends, now avoid double evaluation of their parameters
2015-05-11 20:38:21 +02:00
log_struct(LOG_NOTICE,
"JOB_TYPE=%s", job_type_to_string(t),
"JOB_RESULT=%s", job_result_to_string(result),
LOG_UNIT_ID(u),
LOG_UNIT_MESSAGE(u, "Job %s/%s failed with result '%s'.",
log: fix order of log_unit_struct() to match other logging calls Also, while we are at it, introduce some syntactic sugar for creating ERRNO= and MESSAGE= structured logging fields.
2014-11-28 02:05:14 +01:00
u->id,
job_type_to_string(t),
basic/log: add the log_struct terminator to macro This way all callers do not need to specify it. Exhaustively tested by running test-log under valgrind ;)
2018-06-04 12:59:22 +02:00
job_result_to_string(result)));
unit: introduce OnFailureIsolate=
2011-04-07 04:11:31 +02:00
unit: rework trigger dependency logic Instead of having explicit type-specific callbacks that inform the triggering unit when a triggered unit changes state, make this generic so that state changes are forwarded betwee any triggered and triggering unit. Also, get rid of UnitRef references from automount, timer, path units, to the units they trigger and rely exclsuively on UNIT_TRIGGER type dendencies.
2013-04-23 20:53:16 +02:00
unit_start_on_failure(u);
unit: introduce OnFailureIsolate=
2011-04-07 04:11:31 +02:00
}
job: also trigger on-failure dependencies when jobs faile due to dependencies, timeout
2011-02-24 03:24:23 +01:00
unit: rework trigger dependency logic Instead of having explicit type-specific callbacks that inform the triggering unit when a triggered unit changes state, make this generic so that state changes are forwarded betwee any triggered and triggering unit. Also, get rid of UnitRef references from automount, timer, path units, to the units they trigger and rely exclsuively on UNIT_TRIGGER type dendencies.
2013-04-23 20:53:16 +02:00
unit_trigger_notify(u);
job: after converting a job from restart to start readd it to run queue When we converted a restart job it's time to look again whether any of its dependencies are now runnable. https://bugzilla.redhat.com/show_bug.cgi?id=735013
2011-09-21 19:56:15 +02:00
finish:
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
/* Try to start the next jobs that can be started */
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, u->dependencies[UNIT_AFTER], i)
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
if (other->job) {
unit: remove union Unit Now that objects of all unit types are allocated the exact amount of memory they need, the Unit union has lost its purpose. Remove it. "Unit" is a more natural name for the base unit class than "Meta", so rename Meta to Unit. Access to members of the base class gets simplified.
2012-01-15 12:04:08 +01:00
job_add_to_run_queue(other->job);
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
job_add_to_gc_queue(other->job);
}
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, u->dependencies[UNIT_BEFORE], i)
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
if (other->job) {
unit: remove union Unit Now that objects of all unit types are allocated the exact amount of memory they need, the Unit union has lost its purpose. Remove it. "Unit" is a more natural name for the base unit class than "Meta", so rename Meta to Unit. Access to members of the base class gets simplified.
2012-01-15 12:04:08 +01:00
job_add_to_run_queue(other->job);
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
job_add_to_gc_queue(other->job);
}
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
unit: remove union Unit Now that objects of all unit types are allocated the exact amount of memory they need, the Unit union has lost its purpose. Remove it. "Unit" is a more natural name for the base unit class than "Meta", so rename Meta to Unit. Access to members of the base class gets simplified.
2012-01-15 12:04:08 +01:00
manager_check_finished(u->manager);
manager: measure startup times
2010-09-21 04:14:38 +02:00
transaction: cancel jobs non-recursively on isolate 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
2012-04-24 11:21:03 +02:00
return 0;
first attempt in implementinging execution logic
2010-01-23 01:52:57 +01:00
}
first attempt at proper service/socket logic
2010-01-26 04:18:44 +01:00
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
static int job_dispatch_timer(sd_event_source *s, uint64_t monotonic, void *userdata) {
Job *j = userdata;
job: optionally, when a job timeout is hit, also execute a failure action
2014-10-28 01:49:07 +01:00
Unit *u;
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
assert(j);
assert(s == j->timer_event_source);
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
core,network: major per-object logging rework This changes log_unit_info() (and friends) to take a real Unit* object insted of just a unit name as parameter. The call will now prefix all logged messages with the unit name, thus allowing the unit name to be dropped from the various passed romat strings, simplifying invocations drastically, and unifying log output across messages. Also, UNIT= vs. USER_UNIT= is now derived from the Manager object attached to the Unit object, instead of getpid(). This has the benefit of correcting the field for --test runs. Also contains a couple of other logging improvements: - Drops a couple of strerror() invocations in favour of using %m. - Not only .mount units now warn if a symlinks exist for the mount point already, .automount units do that too, now. - A few invocations of log_struct() that didn't actually pass any additional structured data have been replaced by simpler invocations of log_unit_info() and friends. - For structured data a new LOG_UNIT_MESSAGE() macro has been added, that works like LOG_MESSAGE() but prefixes the message with the unit name. Similar, there's now LOG_LINK_MESSAGE() and LOG_NETDEV_MESSAGE(). - For structured data new LOG_UNIT_ID(), LOG_LINK_INTERFACE(), LOG_NETDEV_INTERFACE() macros have been added that generate the necessary per object fields. The old log_unit_struct() call has been removed in favour of these new macros used in raw log_struct() invocations. In addition to removing one more function call this allows generated structured log messages that contain two object fields, as necessary for example for network interfaces that are joined into another network interface, and whose messages shall be indexed by both. - The LOG_ERRNO() macro has been removed, in favour of log_struct_errno(). The latter has the benefit of ensuring that %m in format strings is properly resolved to the specified error number. - A number of logging messages have been converted to use log_unit_info() instead of log_info() - The client code in sysv-generator no longer #includes core code from src/core/. - log_unit_full_errno() has been removed, log_unit_full() instead takes an errno now, too. - log_unit_info(), log_link_info(), log_netdev_info() and friends, now avoid double evaluation of their parameters
2015-05-11 20:38:21 +02:00
log_unit_warning(j->unit, "Job %s/%s timed out.", j->unit->id, job_type_to_string(j->type));
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
job: optionally, when a job timeout is hit, also execute a failure action
2014-10-28 01:49:07 +01:00
u = j->unit;
core: don't log job status message in case job was effectively NOP (#3199) We currently generate log message about unit being started even when unit was started already and job didn't do anything. This is because job was requested explicitly and hence became anchor job of the transaction thus we could not eliminate it. That is fine but, let's not pollute journal with useless log messages. $ systemctl start systemd-resolved $ systemctl start systemd-resolved $ systemctl start systemd-resolved Current state: $ journalctl -u systemd-resolved | grep Started May 05 15:31:42 rawhide systemd[1]: Started Network Name Resolution. May 05 15:31:59 rawhide systemd[1]: Started Network Name Resolution. May 05 15:32:01 rawhide systemd[1]: Started Network Name Resolution. After patch applied: $ journalctl -u systemd-resolved | grep Started May 05 16:42:12 rawhide systemd[1]: Started Network Name Resolution. Fixes #1723
2016-05-16 17:24:51 +02:00
job_finish_and_invalidate(j, JOB_TIMEOUT, true, false);
job: optionally, when a job timeout is hit, also execute a failure action
2014-10-28 01:49:07 +01:00
core: do not "warn" about mundane emergency actions For example in a container we'd log: Oct 17 17:01:10 rawhide systemd[1]: Started Power-Off. Oct 17 17:01:10 rawhide systemd[1]: Forcibly powering off: unit succeeded Oct 17 17:01:10 rawhide systemd[1]: Reached target Power-Off. Oct 17 17:01:10 rawhide systemd[1]: Shutting down. and on the console we'd write (in red) [ !! ] Forcibly powering off: unit succeeded This is not useful in any way, and the fact that we're calling an "emergency action" is an internal implementation detail. Let's log about c-a-d and the watchdog actions only.
2018-10-17 17:27:20 +02:00
emergency_action(u->manager, u->job_timeout_action,
EMERGENCY_ACTION_IS_WATCHDOG|EMERGENCY_ACTION_WARN,
core: allow to set exit status when using SuccessAction=/FailureAction=exit in units This adds SuccessActionExitStatus= and FailureActionExitStatus= that may be used to configure the exit status to propagate in when SuccessAction=exit or FailureAction=exit is used. When not specified let's also propagate the exit status of the main process we fork off for the unit.
2018-11-16 11:41:18 +01:00
u->job_timeout_reboot_arg, -1, "job timed out");
job: optionally, when a job timeout is hit, also execute a failure action
2014-10-28 01:49:07 +01:00
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
return 0;
}
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
job: add JobRunningTimeoutSec for JOB_RUNNING state Unit.JobTimeoutSec starts when a job is enqueued in a transaction. The introduced distinct Unit.JobRunningTimeoutSec starts only when the job starts running (e.g. it groups all Exec* commands of a service or spans waiting for a device period.) Unit.JobRunningTimeoutSec is intended to be used by default instead of Unit.JobTimeoutSec for device units where such behavior causes less confusion (consider a job for a _netdev mount device, with this change the timeout will start ticking only after the network is ready).
2017-02-17 17:47:20 +01:00
int job_start_timer(Job *j, bool job_running) {
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
int r;
job: Ensure JobRunningTimeoutSec= survives serialization (#6128) This is a fixup of commit a2df3ea4ae058693bc7bf203d144e8af3c9493d2. When there is a running job with JobRunningTimeoutSec= and systemd serializes its state (e.g. during daemon-reload), the timer event source won't be properly restored in job_coldplug(). Thus save and serialize begin_running_usec too and reinitialize the timer based on that value.
2017-06-18 17:51:17 +02:00
usec_t timeout_time, old_timeout_time;
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
job: add JobRunningTimeoutSec for JOB_RUNNING state Unit.JobTimeoutSec starts when a job is enqueued in a transaction. The introduced distinct Unit.JobRunningTimeoutSec starts only when the job starts running (e.g. it groups all Exec* commands of a service or spans waiting for a device period.) Unit.JobRunningTimeoutSec is intended to be used by default instead of Unit.JobTimeoutSec for device units where such behavior causes less confusion (consider a job for a _netdev mount device, with this change the timeout will start ticking only after the network is ready).
2017-02-17 17:47:20 +01:00
if (job_running) {
job: Ensure JobRunningTimeoutSec= survives serialization (#6128) This is a fixup of commit a2df3ea4ae058693bc7bf203d144e8af3c9493d2. When there is a running job with JobRunningTimeoutSec= and systemd serializes its state (e.g. during daemon-reload), the timer event source won't be properly restored in job_coldplug(). Thus save and serialize begin_running_usec too and reinitialize the timer based on that value.
2017-06-18 17:51:17 +02:00
j->begin_running_usec = now(CLOCK_MONOTONIC);
job: add JobRunningTimeoutSec for JOB_RUNNING state Unit.JobTimeoutSec starts when a job is enqueued in a transaction. The introduced distinct Unit.JobRunningTimeoutSec starts only when the job starts running (e.g. it groups all Exec* commands of a service or spans waiting for a device period.) Unit.JobRunningTimeoutSec is intended to be used by default instead of Unit.JobTimeoutSec for device units where such behavior causes less confusion (consider a job for a _netdev mount device, with this change the timeout will start ticking only after the network is ready).
2017-02-17 17:47:20 +01:00
if (j->unit->job_running_timeout == USEC_INFINITY)
return 0;
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
job: Ensure JobRunningTimeoutSec= survives serialization (#6128) This is a fixup of commit a2df3ea4ae058693bc7bf203d144e8af3c9493d2. When there is a running job with JobRunningTimeoutSec= and systemd serializes its state (e.g. during daemon-reload), the timer event source won't be properly restored in job_coldplug(). Thus save and serialize begin_running_usec too and reinitialize the timer based on that value.
2017-06-18 17:51:17 +02:00
timeout_time = usec_add(j->begin_running_usec, j->unit->job_running_timeout);
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
job: add JobRunningTimeoutSec for JOB_RUNNING state Unit.JobTimeoutSec starts when a job is enqueued in a transaction. The introduced distinct Unit.JobRunningTimeoutSec starts only when the job starts running (e.g. it groups all Exec* commands of a service or spans waiting for a device period.) Unit.JobRunningTimeoutSec is intended to be used by default instead of Unit.JobTimeoutSec for device units where such behavior causes less confusion (consider a job for a _netdev mount device, with this change the timeout will start ticking only after the network is ready).
2017-02-17 17:47:20 +01:00
if (j->timer_event_source) {
/* Update only if JobRunningTimeoutSec= results in earlier timeout */
r = sd_event_source_get_time(j->timer_event_source, &old_timeout_time);
if (r < 0)
return r;
if (old_timeout_time <= timeout_time)
return 0;
return sd_event_source_set_time(j->timer_event_source, timeout_time);
}
} else {
if (j->timer_event_source)
return 0;
j->begin_usec = now(CLOCK_MONOTONIC);
if (j->unit->job_timeout == USEC_INFINITY)
return 0;
timeout_time = usec_add(j->begin_usec, j->unit->job_timeout);
}
manager: print ephemeral information about running jobs' timeouts (v2) This reverts commit 28c758de94bc8ba97b89d9dab3f517cf466978d0 but makes job_coldplug smarter. In (v1) I changed the job start timestamp to be always set, so the start time can be reported in the cylon eye message. The bug was that when deserializing jobs, they would be ignored if their start timestamp was unset which was synonymous with no timeout. But after the change, jobs would have a start timestamp set despite having no timeout. After deserialization they would be considered immediately expired. Fix this by checking if the timeout is not zero when considering jobs for expiration.
2014-01-29 00:25:39 +01:00
sd-event: rework API to support CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM, too
2014-03-24 02:49:09 +01:00
r = sd_event_add_time(
j->manager->event,
&j->timer_event_source,
CLOCK_MONOTONIC,
job: add JobRunningTimeoutSec for JOB_RUNNING state Unit.JobTimeoutSec starts when a job is enqueued in a transaction. The introduced distinct Unit.JobRunningTimeoutSec starts only when the job starts running (e.g. it groups all Exec* commands of a service or spans waiting for a device period.) Unit.JobRunningTimeoutSec is intended to be used by default instead of Unit.JobTimeoutSec for device units where such behavior causes less confusion (consider a job for a _netdev mount device, with this change the timeout will start ticking only after the network is ready).
2017-02-17 17:47:20 +01:00
timeout_time, 0,
sd-event: rework API to support CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM, too
2014-03-24 02:49:09 +01:00
job_dispatch_timer, j);
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
if (r < 0)
return r;
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
core: annotate event sources
2015-04-29 16:05:32 +02:00
(void) sd_event_source_set_description(j->timer_event_source, "job-start");
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
return 0;
job: timeout every job independently of the unit
2010-07-17 04:09:28 +02:00
}
dbus: send out signals when units/jobs come, go and change
2010-02-05 00:38:41 +01:00
void job_add_to_run_queue(Job *j) {
job: add log message when we can't enable the job run event source
2018-11-13 19:40:02 +01:00
int r;
first attempt at proper service/socket logic
2010-01-26 04:18:44 +01:00
assert(j);
get rid of 'linked' notion for objects
2010-01-26 19:25:02 +01:00
assert(j->installed);
first attempt at proper service/socket logic
2010-01-26 04:18:44 +01:00
if (j->in_run_queue)
return;
job: add log message when we can't enable the job run event source
2018-11-13 19:40:02 +01:00
if (!j->manager->run_queue) {
r = sd_event_source_set_enabled(j->manager->run_queue_event_source, SD_EVENT_ONESHOT);
if (r < 0)
log_warning_errno(r, "Failed to enable job run queue event source, ignoring: %m");
}
core: dispatch run queue only if there's nothing else to do Always read all external events before we decide what we do next.
2013-11-25 15:22:41 +01:00
list: make our list macros a bit easier to use by not requring type spec on each invocation We can determine the list entry type via the typeof() gcc construct, and so we should to make the macros much shorter to use.
2013-10-14 06:10:14 +02:00
LIST_PREPEND(run_queue, j->manager->run_queue, j);
first attempt at proper service/socket logic
2010-01-26 04:18:44 +01:00
j->in_run_queue = true;
}
greatly extend what we enforce as process properties
2010-01-30 01:55:42 +01:00
dbus: send out signals when units/jobs come, go and change
2010-02-05 00:38:41 +01:00
void job_add_to_dbus_queue(Job *j) {
assert(j);
assert(j->installed);
if (j->in_dbus_queue)
return;
dbus: send signals about jobs to the clients having created them unconditionally, and thus get rid of broadcast signals in most cases
2010-07-05 00:58:07 +02:00
/* We don't check if anybody is subscribed here, since this
* job might just have been created and not yet assigned to a
* connection/client. */
unit,job: when we suppress a D-Bus signal because nobody is listening, don't delay it until later
2010-05-16 03:57:07 +02:00
list: make our list macros a bit easier to use by not requring type spec on each invocation We can determine the list entry type via the typeof() gcc construct, and so we should to make the macros much shorter to use.
2013-10-14 06:10:14 +02:00
LIST_PREPEND(dbus_queue, j->manager->dbus_job_queue, j);
dbus: send out signals when units/jobs come, go and change
2010-02-05 00:38:41 +01:00
j->in_dbus_queue = true;
}
add basic (and not very useful) D-Bus support
2010-02-01 03:33:24 +01:00
char *job_dbus_path(Job *j) {
char *p;
assert(j);
Use format patterns for usec_t, pid_t, nsec_t, usec_t It is nicer to predefine patterns using configure time check instead of using casts everywhere. Since we do not need to use any flags, include "%" in the format instead of excluding it like PRI* macros.
2013-12-30 23:22:26 +01:00
if (asprintf(&p, "/org/freedesktop/systemd1/job/%"PRIu32, j->id) < 0)
add basic (and not very useful) D-Bus support
2010-02-01 03:33:24 +01:00
return NULL;
return p;
}
core: add Ref()/Unref() bus calls for units This adds two (privileged) bus calls Ref() and Unref() to the Unit interface. The two calls may be used by clients to pin a unit into memory, so that various runtime properties aren't flushed out by the automatic GC. This is necessary to permit clients to race-freely acquire runtime results (such as process exit status/code or accumulated CPU time) on successful service termination. Ref() and Unref() are fully recursive, hence act like the usual reference counting concept in C. Taking a reference is a privileged operation, as this allows pinning units into memory which consumes resources. Transient units may also gain a reference at the time of creation, via the new AddRef property (that is only defined for transient units at the time of creation).
2016-08-15 18:12:01 +02:00
int job_serialize(Job *j, FILE *f) {
assert(j);
assert(f);
core: rework serialization Let's be more careful with what we serialize: let's ensure we never serialize strings that are longer than LONG_LINE_MAX, so that we know we can read them back with read_line(…, LONG_LINE_MAX, …) safely. In order to implement this all serialization functions are move to serialize.[ch], and internally will do line size checks. We'd rather skip a serialization line (with a loud warning) than write an overly long line out. Of course, this is just a second level protection, after all the data we serialize shouldn't be this long in the first place. While we are at it also clean up logging: while serializing make sure to always log about errors immediately. Also, (void)ify all calls we don't expect errors in (or catch errors as part of the general fflush_and_check() at the end.
2018-10-17 20:40:09 +02:00
(void) serialize_item_format(f, "job-id", "%u", j->id);
(void) serialize_item(f, "job-type", job_type_to_string(j->type));
(void) serialize_item(f, "job-state", job_state_to_string(j->state));
(void) serialize_bool(f, "job-irreversible", j->irreversible);
(void) serialize_bool(f, "job-sent-dbus-new-signal", j->sent_dbus_new_signal);
(void) serialize_bool(f, "job-ignore-order", j->ignore_order);
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
if (j->begin_usec > 0)
core: rework serialization Let's be more careful with what we serialize: let's ensure we never serialize strings that are longer than LONG_LINE_MAX, so that we know we can read them back with read_line(…, LONG_LINE_MAX, …) safely. In order to implement this all serialization functions are move to serialize.[ch], and internally will do line size checks. We'd rather skip a serialization line (with a loud warning) than write an overly long line out. Of course, this is just a second level protection, after all the data we serialize shouldn't be this long in the first place. While we are at it also clean up logging: while serializing make sure to always log about errors immediately. Also, (void)ify all calls we don't expect errors in (or catch errors as part of the general fflush_and_check() at the end.
2018-10-17 20:40:09 +02:00
(void) serialize_usec(f, "job-begin", j->begin_usec);
job: Ensure JobRunningTimeoutSec= survives serialization (#6128) This is a fixup of commit a2df3ea4ae058693bc7bf203d144e8af3c9493d2. When there is a running job with JobRunningTimeoutSec= and systemd serializes its state (e.g. during daemon-reload), the timer event source won't be properly restored in job_coldplug(). Thus save and serialize begin_running_usec too and reinitialize the timer based on that value.
2017-06-18 17:51:17 +02:00
if (j->begin_running_usec > 0)
core: rework serialization Let's be more careful with what we serialize: let's ensure we never serialize strings that are longer than LONG_LINE_MAX, so that we know we can read them back with read_line(…, LONG_LINE_MAX, …) safely. In order to implement this all serialization functions are move to serialize.[ch], and internally will do line size checks. We'd rather skip a serialization line (with a loud warning) than write an overly long line out. Of course, this is just a second level protection, after all the data we serialize shouldn't be this long in the first place. While we are at it also clean up logging: while serializing make sure to always log about errors immediately. Also, (void)ify all calls we don't expect errors in (or catch errors as part of the general fflush_and_check() at the end.
2018-10-17 20:40:09 +02:00
(void) serialize_usec(f, "job-begin-running", j->begin_running_usec);
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
core: rename "clients" field of Job structure to "bus_track" Let's make semantics of this field more similar to the same functionality in the Unit object, in particular as we add new functionality to it later on.
2016-11-15 19:29:50 +01:00
bus_track_serialize(j->bus_track, f, "subscribed");
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
/* End marker */
fputc('\n', f);
return 0;
}
core: add Ref()/Unref() bus calls for units This adds two (privileged) bus calls Ref() and Unref() to the Unit interface. The two calls may be used by clients to pin a unit into memory, so that various runtime properties aren't flushed out by the automatic GC. This is necessary to permit clients to race-freely acquire runtime results (such as process exit status/code or accumulated CPU time) on successful service termination. Ref() and Unref() are fully recursive, hence act like the usual reference counting concept in C. Taking a reference is a privileged operation, as this allows pinning units into memory which consumes resources. Transient units may also gain a reference at the time of creation, via the new AddRef property (that is only defined for transient units at the time of creation).
2016-08-15 18:12:01 +02:00
int job_deserialize(Job *j, FILE *f) {
core: when deserializing state always use read_line(…, LONG_LINE_MAX, …) This should be much better than fgets(), as we can read substantially longer lines and overly long lines result in proper errors. Fixes a vulnerability discovered by Jann Horn at Google. CVE-2018-15686 LP: #1796402 https://bugzilla.redhat.com/show_bug.cgi?id=1639071
2018-10-17 18:36:24 +02:00
int r;
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
assert(j);
core: add Ref()/Unref() bus calls for units This adds two (privileged) bus calls Ref() and Unref() to the Unit interface. The two calls may be used by clients to pin a unit into memory, so that various runtime properties aren't flushed out by the automatic GC. This is necessary to permit clients to race-freely acquire runtime results (such as process exit status/code or accumulated CPU time) on successful service termination. Ref() and Unref() are fully recursive, hence act like the usual reference counting concept in C. Taking a reference is a privileged operation, as this allows pinning units into memory which consumes resources. Transient units may also gain a reference at the time of creation, via the new AddRef property (that is only defined for transient units at the time of creation).
2016-08-15 18:12:01 +02:00
assert(f);
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
for (;;) {
core: when deserializing state always use read_line(…, LONG_LINE_MAX, …) This should be much better than fgets(), as we can read substantially longer lines and overly long lines result in proper errors. Fixes a vulnerability discovered by Jann Horn at Google. CVE-2018-15686 LP: #1796402 https://bugzilla.redhat.com/show_bug.cgi?id=1639071
2018-10-17 18:36:24 +02:00
_cleanup_free_ char *line = NULL;
char *l, *v;
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
size_t k;
core: when deserializing state always use read_line(…, LONG_LINE_MAX, …) This should be much better than fgets(), as we can read substantially longer lines and overly long lines result in proper errors. Fixes a vulnerability discovered by Jann Horn at Google. CVE-2018-15686 LP: #1796402 https://bugzilla.redhat.com/show_bug.cgi?id=1639071
2018-10-17 18:36:24 +02:00
r = read_line(f, LONG_LINE_MAX, &line);
if (r < 0)
return log_error_errno(r, "Failed to read serialization line: %m");
if (r == 0)
return 0;
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
l = strstrip(line);
/* End marker */
core: when deserializing state always use read_line(…, LONG_LINE_MAX, …) This should be much better than fgets(), as we can read substantially longer lines and overly long lines result in proper errors. Fixes a vulnerability discovered by Jann Horn at Google. CVE-2018-15686 LP: #1796402 https://bugzilla.redhat.com/show_bug.cgi?id=1639071
2018-10-17 18:36:24 +02:00
if (isempty(l))
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
return 0;
k = strcspn(l, "=");
if (l[k] == '=') {
l[k] = 0;
v = l+k+1;
} else
v = l+k;
if (streq(l, "job-id")) {
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
if (safe_atou32(v, &j->id) < 0)
job: add lots of colons to log messages
2018-10-17 20:16:52 +02:00
log_debug("Failed to parse job id value: %s", v);
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
} else if (streq(l, "job-type")) {
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
JobType t;
t = job_type_from_string(v);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
if (t < 0)
job: add lots of colons to log messages
2018-10-17 20:16:52 +02:00
log_debug("Failed to parse job type: %s", v);
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
else if (t >= _JOB_TYPE_MAX_IN_TRANSACTION)
job: add lots of colons to log messages
2018-10-17 20:16:52 +02:00
log_debug("Cannot deserialize job of type: %s", v);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
else
j->type = t;
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
} else if (streq(l, "job-state")) {
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
JobState s;
s = job_state_from_string(v);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
if (s < 0)
job: add lots of colons to log messages
2018-10-17 20:16:52 +02:00
log_debug("Failed to parse job state: %s", v);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
else
core: rework counting of running jobs Let's unify the code that counts the running jobs a bit, in order to make sure we are less likely to miss one. This is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=87349 However, it probably won't fix it fully, and I cannot reproduce the issue. The change also adds an explicit assert change when the counter is off.
2015-01-05 17:22:10 +01:00
job_set_state(j, s);
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
core, systemctl: add support for irreversible jobs Add a new job mode: replace-irreversibly. Jobs enqueued using this mode cannot be implicitly canceled by later enqueued conflicting jobs. They can however still be canceled with an explicit "systemctl cancel" call.
2013-02-22 11:21:37 +01:00
} else if (streq(l, "job-irreversible")) {
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
int b;
b = parse_boolean(v);
core, systemctl: add support for irreversible jobs Add a new job mode: replace-irreversibly. Jobs enqueued using this mode cannot be implicitly canceled by later enqueued conflicting jobs. They can however still be canceled with an explicit "systemctl cancel" call.
2013-02-22 11:21:37 +01:00
if (b < 0)
job: add lots of colons to log messages
2018-10-17 20:16:52 +02:00
log_debug("Failed to parse job irreversible flag: %s", v);
core, systemctl: add support for irreversible jobs Add a new job mode: replace-irreversibly. Jobs enqueued using this mode cannot be implicitly canceled by later enqueued conflicting jobs. They can however still be canceled with an explicit "systemctl cancel" call.
2013-02-22 11:21:37 +01:00
else
j->irreversible = j->irreversible || b;
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
} else if (streq(l, "job-sent-dbus-new-signal")) {
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
int b;
b = parse_boolean(v);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
if (b < 0)
job: add lots of colons to log messages
2018-10-17 20:16:52 +02:00
log_debug("Failed to parse job sent_dbus_new_signal flag: %s", v);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
else
j->sent_dbus_new_signal = j->sent_dbus_new_signal || b;
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
} else if (streq(l, "job-ignore-order")) {
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
int b;
b = parse_boolean(v);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
if (b < 0)
job: add lots of colons to log messages
2018-10-17 20:16:52 +02:00
log_debug("Failed to parse job ignore_order flag: %s", v);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
else
j->ignore_order = j->ignore_order || b;
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
core: rework serialization Let's be more careful with what we serialize: let's ensure we never serialize strings that are longer than LONG_LINE_MAX, so that we know we can read them back with read_line(…, LONG_LINE_MAX, …) safely. In order to implement this all serialization functions are move to serialize.[ch], and internally will do line size checks. We'd rather skip a serialization line (with a loud warning) than write an overly long line out. Of course, this is just a second level protection, after all the data we serialize shouldn't be this long in the first place. While we are at it also clean up logging: while serializing make sure to always log about errors immediately. Also, (void)ify all calls we don't expect errors in (or catch errors as part of the general fflush_and_check() at the end.
2018-10-17 20:40:09 +02:00
} else if (streq(l, "job-begin"))
(void) deserialize_usec(v, &j->begin_usec);
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
core: rework serialization Let's be more careful with what we serialize: let's ensure we never serialize strings that are longer than LONG_LINE_MAX, so that we know we can read them back with read_line(…, LONG_LINE_MAX, …) safely. In order to implement this all serialization functions are move to serialize.[ch], and internally will do line size checks. We'd rather skip a serialization line (with a loud warning) than write an overly long line out. Of course, this is just a second level protection, after all the data we serialize shouldn't be this long in the first place. While we are at it also clean up logging: while serializing make sure to always log about errors immediately. Also, (void)ify all calls we don't expect errors in (or catch errors as part of the general fflush_and_check() at the end.
2018-10-17 20:40:09 +02:00
else if (streq(l, "job-begin-running"))
(void) deserialize_usec(v, &j->begin_running_usec);
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
core: rework serialization Let's be more careful with what we serialize: let's ensure we never serialize strings that are longer than LONG_LINE_MAX, so that we know we can read them back with read_line(…, LONG_LINE_MAX, …) safely. In order to implement this all serialization functions are move to serialize.[ch], and internally will do line size checks. We'd rather skip a serialization line (with a loud warning) than write an overly long line out. Of course, this is just a second level protection, after all the data we serialize shouldn't be this long in the first place. While we are at it also clean up logging: while serializing make sure to always log about errors immediately. Also, (void)ify all calls we don't expect errors in (or catch errors as part of the general fflush_and_check() at the end.
2018-10-17 20:40:09 +02:00
else if (streq(l, "subscribed")) {
core: Rename Job.subscribed field to Job.clients This reflects how this field will be used, to not only track where to send signals, but also which callers (other than root) are allowed to call DBus methods on the Job.
2014-08-06 11:53:00 +02:00
if (strv_extend(&j->deserialized_clients, v) < 0)
core: rework serialization Let's be more careful with what we serialize: let's ensure we never serialize strings that are longer than LONG_LINE_MAX, so that we know we can read them back with read_line(…, LONG_LINE_MAX, …) safely. In order to implement this all serialization functions are move to serialize.[ch], and internally will do line size checks. We'd rather skip a serialization line (with a loud warning) than write an overly long line out. Of course, this is just a second level protection, after all the data we serialize shouldn't be this long in the first place. While we are at it also clean up logging: while serializing make sure to always log about errors immediately. Also, (void)ify all calls we don't expect errors in (or catch errors as part of the general fflush_and_check() at the end.
2018-10-17 20:40:09 +02:00
return log_oom();
} else
log_debug("Unknown job serialization key: %s", l);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
}
}
int job_coldplug(Job *j) {
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
int r;
job: Ensure JobRunningTimeoutSec= survives serialization (#6128) This is a fixup of commit a2df3ea4ae058693bc7bf203d144e8af3c9493d2. When there is a running job with JobRunningTimeoutSec= and systemd serializes its state (e.g. during daemon-reload), the timer event source won't be properly restored in job_coldplug(). Thus save and serialize begin_running_usec too and reinitialize the timer based on that value.
2017-06-18 17:51:17 +02:00
usec_t timeout_time = USEC_INFINITY;
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
assert(j);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
bus: add sd_bus_track object for tracking peers, and port core over to it This is primarily useful for services that need to track clients which reference certain objects they maintain, or which explicitly want to subscribe to certain events. Something like this is done in a large number of services, and not trivial to do. Hence, let's unify this at one place. This also ports over PID 1 to use this to ensure that subscriptions to job and manager events are correctly tracked. As a side-effect this makes sure we properly serialize and restore the track list across daemon reexec/reload, which didn't work correctly before. This also simplifies how we distribute messages to broadcast to the direct busses: we only track subscriptions for the API bus and implicitly assume that all direct busses are subscribed. This should be a pretty OK simplification since clients connected via direct bus connections are shortlived anyway.
2014-03-03 01:33:45 +01:00
/* After deserialization is complete and the bus connection
* set up again, let's start watching our subscribers again */
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
(void) bus_job_coldplug_bus_track(j);
bus: add sd_bus_track object for tracking peers, and port core over to it This is primarily useful for services that need to track clients which reference certain objects they maintain, or which explicitly want to subscribe to certain events. Something like this is done in a large number of services, and not trivial to do. Hence, let's unify this at one place. This also ports over PID 1 to use this to ensure that subscriptions to job and manager events are correctly tracked. As a side-effect this makes sure we properly serialize and restore the track list across daemon reexec/reload, which didn't work correctly before. This also simplifies how we distribute messages to broadcast to the direct busses: we only track subscriptions for the API bus and implicitly assume that all direct busses are subscribed. This should be a pretty OK simplification since clients connected via direct bus connections are shortlived anyway.
2014-03-03 01:33:45 +01:00
job: always add waiting jobs to run queue during coldplug commit 20a83d7bf was not equivalent to the original bug fix proposed by Michal Sekletar <msekleta@redhat.com>. The committed version only added the job to the run queue if the job had a timeout, which most jobs do not have. Just re-ordering the code gets us the intended functionality
2014-05-12 09:26:16 +02:00
if (j->state == JOB_WAITING)
job_add_to_run_queue(j);
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
/* Maybe due to new dependencies we don't actually need this job anymore? */
job_add_to_gc_queue(j);
job: Ensure JobRunningTimeoutSec= survives serialization (#6128) This is a fixup of commit a2df3ea4ae058693bc7bf203d144e8af3c9493d2. When there is a running job with JobRunningTimeoutSec= and systemd serializes its state (e.g. during daemon-reload), the timer event source won't be properly restored in job_coldplug(). Thus save and serialize begin_running_usec too and reinitialize the timer based on that value.
2017-06-18 17:51:17 +02:00
/* Create timer only when job began or began running and the respective timeout is finite.
* Follow logic of job_start_timer() if both timeouts are finite */
if (j->begin_usec == 0)
return 0;
if (j->unit->job_timeout != USEC_INFINITY)
timeout_time = usec_add(j->begin_usec, j->unit->job_timeout);
basic/time-util: add helper function to check if timestamp is set No functional change.
2019-07-04 19:10:11 +02:00
if (timestamp_is_set(j->begin_running_usec))
job: Ensure JobRunningTimeoutSec= survives serialization (#6128) This is a fixup of commit a2df3ea4ae058693bc7bf203d144e8af3c9493d2. When there is a running job with JobRunningTimeoutSec= and systemd serializes its state (e.g. during daemon-reload), the timer event source won't be properly restored in job_coldplug(). Thus save and serialize begin_running_usec too and reinitialize the timer based on that value.
2017-06-18 17:51:17 +02:00
timeout_time = MIN(timeout_time, usec_add(j->begin_running_usec, j->unit->job_running_timeout));
if (timeout_time == USEC_INFINITY)
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
return 0;
core: rework unit timeout handling, and add new setting RuntimeMaxSec= This clean-ups timeout handling in PID 1. Specifically, instead of storing 0 in internal timeout variables as indication for a disabled timeout, use USEC_INFINITY which is in-line with how we do this in the rest of our code (following the logic that 0 means "no", and USEC_INFINITY means "never"). This also replace all usec_t additions with invocations to usec_add(), so that USEC_INFINITY is properly propagated, and sd-event considers it has indication for turning off the event source. This also alters the deserialization of the units to restart timeouts from the time they were originally started from. Before this patch timeouts would be restarted beginning with the time of the deserialization, which could lead to artificially prolonged timeouts if a daemon reload took place. Finally, a new RuntimeMaxSec= setting is introduced for service units, that specifies a maximum runtime after which a specific service is forcibly terminated. This is useful to put time limits on time-intensive processing jobs. This also simplifies the various xyz_spawn() calls of the various types in that explicit distruction of the timers is removed, as that is done anyway by the state change handlers, and a state change is always done when the xyz_spawn() calls fail. Fixes: #2249
2016-02-01 21:48:10 +01:00
j->timer_event_source = sd_event_source_unref(j->timer_event_source);
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
sd-event: rework API to support CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM, too
2014-03-24 02:49:09 +01:00
r = sd_event_add_time(
j->manager->event,
&j->timer_event_source,
CLOCK_MONOTONIC,
job: Ensure JobRunningTimeoutSec= survives serialization (#6128) This is a fixup of commit a2df3ea4ae058693bc7bf203d144e8af3c9493d2. When there is a running job with JobRunningTimeoutSec= and systemd serializes its state (e.g. during daemon-reload), the timer event source won't be properly restored in job_coldplug(). Thus save and serialize begin_running_usec too and reinitialize the timer based on that value.
2017-06-18 17:51:17 +02:00
timeout_time, 0,
sd-event: rework API to support CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM, too
2014-03-24 02:49:09 +01:00
job_dispatch_timer, j);
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
if (r < 0)
treewide: no need to negate errno for log_*_errno() It corrrectly handles both positive and negative errno values.
2014-11-28 13:19:16 +01:00
log_debug_errno(r, "Failed to restart timeout for job: %m");
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
core: annotate event sources
2015-04-29 16:05:32 +02:00
(void) sd_event_source_set_description(j->timer_event_source, "job-timeout");
core: convert PID 1 to libsystemd-bus This patch converts PID 1 to libsystemd-bus and thus drops the dependency on libdbus. The only remaining code using libdbus is a test case that validates our bus marshalling against libdbus' marshalling, and this dependency can be turned off. This patch also adds a couple of things to libsystem-bus, that are necessary to make the port work: - Synthesizing of "Disconnected" messages when bus connections are severed. - Support for attaching multiple vtables for the same interface on the same path. This patch also fixes the SetDefaultTarget() and GetDefaultTarget() bus calls which used an inappropriate signature. As a side effect we will now generate PropertiesChanged messages which carry property contents, rather than just invalidation information.
2013-11-19 21:12:59 +01:00
return r;
job: serialize jobs properly 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.
2012-04-23 01:24:04 +02:00
}
shutdown: issue a sync() as soon as shutdown.target is queued
2013-01-25 22:33:33 +01:00
void job_shutdown_magic(Job *j) {
assert(j);
/* The shutdown target gets some special treatment here: we
* tell the kernel to begin with flushing its disk caches, to
* optimize shutdown time a bit. Ideally we wouldn't hardcode
* this magic into PID 1. However all other processes aren't
* options either since they'd exit much sooner than PID 1 and
* asynchronous sync() would cause their exit to be
* delayed. */
core: add transient units Transient units can be created via the bus API. They are configured via the method call parameters rather than on-disk files. They are subject to normal GC. Transient units currently may only be created for services (however, we will extend this), and currently only ExecStart= and the cgroup parameters can be configured (also to be extended). Transient units require a unique name, that previously had no configuration file on disk. A tool systemd-run is added that makes use of this functionality to run arbitrary command lines as transient services: $ systemd-run /bin/ping www.heise.de Will cause systemd to create a new transient service and run ping in it.
2013-06-28 04:12:58 +02:00
if (j->type != JOB_START)
shutdown: issue a sync() as soon as shutdown.target is queued
2013-01-25 22:33:33 +01:00
return;
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
if (!MANAGER_IS_SYSTEM(j->unit->manager))
core: add transient units Transient units can be created via the bus API. They are configured via the method call parameters rather than on-disk files. They are subject to normal GC. Transient units currently may only be created for services (however, we will extend this), and currently only ExecStart= and the cgroup parameters can be configured (also to be extended). Transient units require a unique name, that previously had no configuration file on disk. A tool systemd-run is added that makes use of this functionality to run arbitrary command lines as transient services: $ systemd-run /bin/ping www.heise.de Will cause systemd to create a new transient service and run ping in it.
2013-06-28 04:12:58 +02:00
return;
if (!unit_has_name(j->unit, SPECIAL_SHUTDOWN_TARGET))
shutdown: issue a sync() as soon as shutdown.target is queued
2013-01-25 22:33:33 +01:00
return;
Fix possible lack of status messages on shutdown/reboot Since 31a7eb86 the output on console can be disabled to avoid colliding with gettys. However, it could also lead to a lack of messages during shutdown/reboot.
2013-09-20 22:18:30 +02:00
/* In case messages on console has been disabled on boot */
j->unit->manager->no_console_output = false;
basic: rework virtualization detection API Introduce a proper enum, and don't pass around string ids anymore. This simplifies things quite a bit, and makes virtualization detection more similar to architecture detection.
2015-09-07 13:42:47 +02:00
if (detect_container() > 0)
shutdown: issue a sync() as soon as shutdown.target is queued
2013-01-25 22:33:33 +01:00
return;
shutdown: unify shutdown.c's and async.c's sync() helper process The helper processes are pretty much the same now, let's unify them hence.
2017-12-22 13:19:56 +01:00
(void) asynchronous_sync(NULL);
shutdown: issue a sync() as soon as shutdown.target is queued
2013-01-25 22:33:33 +01:00
}
core: rework job_get_timeout() to use usec_t and handle USEC_INFINITY time events correctly
2016-02-04 00:35:43 +01:00
int job_get_timeout(Job *j, usec_t *timeout) {
usec_t x = USEC_INFINITY, y = USEC_INFINITY;
core: add function to tell when job will time out Things will continue when either the job timeout or the unit timeout is reached. Add functionality to access that info.
2014-01-27 06:57:34 +01:00
Unit *u = j->unit;
core: rework job_get_timeout() to use usec_t and handle USEC_INFINITY time events correctly
2016-02-04 00:35:43 +01:00
int r;
core: add function to tell when job will time out Things will continue when either the job timeout or the unit timeout is reached. Add functionality to access that info.
2014-01-27 06:57:34 +01:00
assert(u);
if (j->timer_event_source) {
r = sd_event_source_get_time(j->timer_event_source, &x);
if (r < 0)
return r;
}
if (UNIT_VTABLE(u)->get_timeout) {
core: rework job_get_timeout() to use usec_t and handle USEC_INFINITY time events correctly
2016-02-04 00:35:43 +01:00
r = UNIT_VTABLE(u)->get_timeout(u, &y);
if (r < 0)
return r;
core: add function to tell when job will time out Things will continue when either the job timeout or the unit timeout is reached. Add functionality to access that info.
2014-01-27 06:57:34 +01:00
}
core: rework job_get_timeout() to use usec_t and handle USEC_INFINITY time events correctly
2016-02-04 00:35:43 +01:00
if (x == USEC_INFINITY && y == USEC_INFINITY)
core: add function to tell when job will time out Things will continue when either the job timeout or the unit timeout is reached. Add functionality to access that info.
2014-01-27 06:57:34 +01:00
return 0;
*timeout = MIN(x, y);
return 1;
}
pid1: rename job_check_gc to job_may_gc The reasoning is the same as for unit_can_gc. v2: - rename can_gc to may_gc
2018-02-14 00:39:06 +01:00
bool job_may_gc(Job *j) {
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
Unit *other;
Iterator i;
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
void *v;
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
assert(j);
/* Checks whether this job should be GC'ed away. We only do this for jobs of units that have no effect on their
pid1: rename job_check_gc to job_may_gc The reasoning is the same as for unit_can_gc. v2: - rename can_gc to may_gc
2018-02-14 00:39:06 +01:00
* own and just track external state. For now the only unit type that qualifies for this are .device units.
* Returns true if the job can be collected. */
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
if (!UNIT_VTABLE(j->unit)->gc_jobs)
pid1: rename job_check_gc to job_may_gc The reasoning is the same as for unit_can_gc. v2: - rename can_gc to may_gc
2018-02-14 00:39:06 +01:00
return false;
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
if (sd_bus_track_count(j->bus_track) > 0)
pid1: rename job_check_gc to job_may_gc The reasoning is the same as for unit_can_gc. v2: - rename can_gc to may_gc
2018-02-14 00:39:06 +01:00
return false;
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
/* FIXME: So this is a bit ugly: for now we don't properly track references made via private bus connections
* (because it's nasty, as sd_bus_track doesn't apply to it). We simply remember that the job was once
* referenced by one, and reset this whenever we notice that no private bus connections are around. This means
* the GC is a bit too conservative when it comes to jobs created by private bus connections. */
if (j->ref_by_private_bus) {
if (set_isempty(j->unit->manager->private_buses))
j->ref_by_private_bus = false;
else
pid1: rename job_check_gc to job_may_gc The reasoning is the same as for unit_can_gc. v2: - rename can_gc to may_gc
2018-02-14 00:39:06 +01:00
return false;
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
}
if (j->type == JOB_NOP)
pid1: rename job_check_gc to job_may_gc The reasoning is the same as for unit_can_gc. v2: - rename can_gc to may_gc
2018-02-14 00:39:06 +01:00
return false;
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
/* If a job is ordered after ours, and is to be started, then it needs to wait for us, regardless if we stop or
* start, hence let's not GC in that case. */
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, j->unit->dependencies[UNIT_BEFORE], i) {
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
if (!other->job)
continue;
if (other->job->ignore_order)
continue;
if (IN_SET(other->job->type, JOB_START, JOB_VERIFY_ACTIVE, JOB_RELOAD))
pid1: rename job_check_gc to job_may_gc The reasoning is the same as for unit_can_gc. v2: - rename can_gc to may_gc
2018-02-14 00:39:06 +01:00
return false;
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
}
core: do not print color console message about gc-ed jobs This is just a cosmetic issue. Garbage collection of jobs (especially the ones that we create automatically) is something of an internal implementation detail and should not be made visible to the users. But it's probably still useful to log this in the journal, so the code is rearranged to skip one of the messages if we log to the console and the journal separately, and to keep the message if we log everything to the console. Fixes #6254.
2017-07-02 01:05:36 +02:00
/* If we are going down, but something else is ordered After= us, then it needs to wait for us */
if (IN_SET(j->type, JOB_STOP, JOB_RESTART))
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, j->unit->dependencies[UNIT_AFTER], i) {
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
if (!other->job)
continue;
if (other->job->ignore_order)
continue;
pid1: rename job_check_gc to job_may_gc The reasoning is the same as for unit_can_gc. v2: - rename can_gc to may_gc
2018-02-14 00:39:06 +01:00
return false;
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
}
/* The logic above is kinda the inverse of the job_is_runnable() logic. Specifically, if the job "we" is
* ordered before the job "other":
*
* we start + other start → stay
* we start + other stop → gc
* we stop + other start → stay
* we stop + other stop → gc
*
* "we" are ordered after "other":
*
* we start + other start → gc
* we start + other stop → gc
* we stop + other start → stay
* we stop + other stop → stay
*/
pid1: rename job_check_gc to job_may_gc The reasoning is the same as for unit_can_gc. v2: - rename can_gc to may_gc
2018-02-14 00:39:06 +01:00
return true;
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
}
void job_add_to_gc_queue(Job *j) {
assert(j);
if (j->in_gc_queue)
return;
pid1: rename job_check_gc to job_may_gc The reasoning is the same as for unit_can_gc. v2: - rename can_gc to may_gc
2018-02-14 00:39:06 +01:00
if (!job_may_gc(j))
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
return;
LIST_PREPEND(gc_queue, j->unit->manager->gc_job_queue, j);
j->in_gc_queue = true;
}
tree-wide: use typesafe_qsort()
2018-09-18 01:39:24 +02:00
static int job_compare(Job * const *a, Job * const *b) {
return CMP((*a)->id, (*b)->id);
core: add bus calls for determining jobs waiting for other jobs This should make it easier to debug job deadlocks.
2016-11-16 16:07:32 +01:00
}
static size_t sort_job_list(Job **list, size_t n) {
Job *previous = NULL;
size_t a, b;
/* Order by numeric IDs */
tree-wide: use typesafe_qsort()
2018-09-18 01:39:24 +02:00
typesafe_qsort(list, n, job_compare);
core: add bus calls for determining jobs waiting for other jobs This should make it easier to debug job deadlocks.
2016-11-16 16:07:32 +01:00
/* Filter out duplicates */
for (a = 0, b = 0; a < n; a++) {
if (previous == list[a])
continue;
previous = list[b++] = list[a];
}
return b;
}
int job_get_before(Job *j, Job*** ret) {
_cleanup_free_ Job** list = NULL;
size_t n = 0, n_allocated = 0;
Unit *other = NULL;
Iterator i;
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
void *v;
core: add bus calls for determining jobs waiting for other jobs This should make it easier to debug job deadlocks.
2016-11-16 16:07:32 +01:00
/* Returns a list of all pending jobs that need to finish before this job may be started. */
assert(j);
assert(ret);
if (j->ignore_order) {
*ret = NULL;
return 0;
}
if (IN_SET(j->type, JOB_START, JOB_VERIFY_ACTIVE, JOB_RELOAD)) {
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, j->unit->dependencies[UNIT_AFTER], i) {
core: add bus calls for determining jobs waiting for other jobs This should make it easier to debug job deadlocks.
2016-11-16 16:07:32 +01:00
if (!other->job)
continue;
if (!GREEDY_REALLOC(list, n_allocated, n+1))
return -ENOMEM;
list[n++] = other->job;
}
}
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, j->unit->dependencies[UNIT_BEFORE], i) {
core: add bus calls for determining jobs waiting for other jobs This should make it easier to debug job deadlocks.
2016-11-16 16:07:32 +01:00
if (!other->job)
continue;
if (!IN_SET(other->job->type, JOB_STOP, JOB_RESTART))
continue;
if (!GREEDY_REALLOC(list, n_allocated, n+1))
return -ENOMEM;
list[n++] = other->job;
}
n = sort_job_list(list, n);
tree-wide: use TAKE_PTR() and TAKE_FD() macros
2018-04-05 07:26:26 +02:00
*ret = TAKE_PTR(list);
core: add bus calls for determining jobs waiting for other jobs This should make it easier to debug job deadlocks.
2016-11-16 16:07:32 +01:00
return (int) n;
}
int job_get_after(Job *j, Job*** ret) {
_cleanup_free_ Job** list = NULL;
size_t n = 0, n_allocated = 0;
Unit *other = NULL;
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
void *v;
core: add bus calls for determining jobs waiting for other jobs This should make it easier to debug job deadlocks.
2016-11-16 16:07:32 +01:00
Iterator i;
assert(j);
assert(ret);
/* Returns a list of all pending jobs that are waiting for this job to finish. */
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, j->unit->dependencies[UNIT_BEFORE], i) {
core: add bus calls for determining jobs waiting for other jobs This should make it easier to debug job deadlocks.
2016-11-16 16:07:32 +01:00
if (!other->job)
continue;
if (other->job->ignore_order)
continue;
if (!IN_SET(other->job->type, JOB_START, JOB_VERIFY_ACTIVE, JOB_RELOAD))
continue;
if (!GREEDY_REALLOC(list, n_allocated, n+1))
return -ENOMEM;
list[n++] = other->job;
}
if (IN_SET(j->type, JOB_STOP, JOB_RESTART)) {
core: track why unit dependencies came to be This replaces the dependencies Set* objects by Hashmap* objects, where the key is the depending Unit, and the value is a bitmask encoding why the specific dependency was created. The bitmask contains a number of different, defined bits, that indicate why dependencies exist, for example whether they are created due to explicitly configured deps in files, by udev rules or implicitly. Note that memory usage is not increased by this change, even though we store more information, as we manage to encode the bit mask inside the value pointer each Hashmap entry contains. Why this all? When we know how a dependency came to be, we can update dependencies correctly when a configuration source changes but others are left unaltered. Specifically: 1. We can fix UDEV_WANTS dependency generation: so far we kept adding dependencies configured that way, but if a device lost such a dependency we couldn't them again as there was no scheme for removing of dependencies in place. 2. We can implement "pin-pointed" reload of unit files. If we know what dependencies were created as result of configuration in a unit file, then we know what to flush out when we want to reload it. 3. It's useful for debugging: "systemd-analyze dump" now shows this information, helping substantially with understanding how systemd's dependency tree came to be the way it came to be.
2017-10-25 20:46:01 +02:00
HASHMAP_FOREACH_KEY(v, other, j->unit->dependencies[UNIT_AFTER], i) {
core: add bus calls for determining jobs waiting for other jobs This should make it easier to debug job deadlocks.
2016-11-16 16:07:32 +01:00
if (!other->job)
continue;
if (other->job->ignore_order)
continue;
if (!GREEDY_REALLOC(list, n_allocated, n+1))
return -ENOMEM;
list[n++] = other->job;
}
}
n = sort_job_list(list, n);
tree-wide: use TAKE_PTR() and TAKE_FD() macros
2018-04-05 07:26:26 +02:00
*ret = TAKE_PTR(list);
core: add bus calls for determining jobs waiting for other jobs This should make it easier to debug job deadlocks.
2016-11-16 16:07:32 +01:00
return (int) n;
}
greatly extend what we enforce as process properties
2010-01-30 01:55:42 +01:00
static const char* const job_state_table[_JOB_STATE_MAX] = {
[JOB_WAITING] = "waiting",
core: a few small coding style/modernization updates for job.c
2016-11-15 19:19:57 +01:00
[JOB_RUNNING] = "running",
greatly extend what we enforce as process properties
2010-01-30 01:55:42 +01:00
};
DEFINE_STRING_TABLE_LOOKUP(job_state, JobState);
static const char* const job_type_table[_JOB_TYPE_MAX] = {
[JOB_START] = "start",
[JOB_VERIFY_ACTIVE] = "verify-active",
[JOB_STOP] = "stop",
[JOB_RELOAD] = "reload",
[JOB_RELOAD_OR_START] = "reload-or-start",
[JOB_RESTART] = "restart",
[JOB_TRY_RESTART] = "try-restart",
core: make sure "systemctl reload-or-try-restart is actually a noop if a unit is not running This makes sure we follow the same basic logic for try-restart if we have a try-reload. Fixes #688
2016-01-28 18:48:42 +01:00
[JOB_TRY_RELOAD] = "try-reload",
core: add NOP jobs, job type collapsing 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
2012-04-25 11:58:27 +02:00
[JOB_NOP] = "nop",
greatly extend what we enforce as process properties
2010-01-30 01:55:42 +01:00
};
DEFINE_STRING_TABLE_LOOKUP(job_type, JobType);
dbus: implement start/stop/restart/reload/cancel D-Bus calls
2010-02-03 12:37:42 +01:00
static const char* const job_mode_table[_JOB_MODE_MAX] = {
[JOB_FAIL] = "fail",
manager: introduce 'isolate' job mode which kills all units but the requested one
2010-04-22 02:42:59 +02:00
[JOB_REPLACE] = "replace",
core, systemctl: add support for irreversible jobs Add a new job mode: replace-irreversibly. Jobs enqueued using this mode cannot be implicitly canceled by later enqueued conflicting jobs. They can however still be canceled with an explicit "systemctl cancel" call.
2013-02-22 11:21:37 +01:00
[JOB_REPLACE_IRREVERSIBLY] = "replace-irreversibly",
systemctl: introduce --ignore-dependencies
2011-02-16 21:59:31 +01:00
[JOB_ISOLATE] = "isolate",
Make tables for DEFINE_STRING_TABLE_LOOKUP consistent Bring some arrays that are used for DEFINE_STRING_TABLE_LOOKUP() in the same order than the enums they reference. Also, pass the corresponding _MAX value to the array initalizer where appropriate.
2014-03-07 21:38:48 +01:00
[JOB_FLUSH] = "flush",
job: fix deserialization of jobs: do not ignore ordering
2011-04-06 19:09:33 +02:00
[JOB_IGNORE_DEPENDENCIES] = "ignore-dependencies",
core: add new "flush" job mode to cancel all other jobs when queuing a new job
2013-11-26 02:13:41 +01:00
[JOB_IGNORE_REQUIREMENTS] = "ignore-requirements",
dbus: implement start/stop/restart/reload/cancel D-Bus calls
2010-02-03 12:37:42 +01:00
};
DEFINE_STRING_TABLE_LOOKUP(job_mode, JobMode);
dbus: pass along information why a job failed when it failed (dbus api change!)
2011-02-24 02:36:34 +01:00
static const char* const job_result_table[_JOB_RESULT_MAX] = {
[JOB_DONE] = "done",
[JOB_CANCELED] = "canceled",
[JOB_TIMEOUT] = "timeout",
[JOB_FAILED] = "failed",
job: introduce new job result code 'skipped' to use when pre conditions of job did not apply https://bugzilla.redhat.com/show_bug.cgi?id=682245 https://bugzilla.redhat.com/show_bug.cgi?id=635780
2011-03-08 01:44:19 +01:00
[JOB_DEPENDENCY] = "dependency",
systemd: treat reload failure as failure systemctl reload "suceeded" on stopped units, but it is documented to fail in this case. https://bugzilla.redhat.com/show_bug.cgi?id=1036845
2013-12-03 03:52:51 +01:00
[JOB_SKIPPED] = "skipped",
[JOB_INVALID] = "invalid",
core: introduce the concept of AssertXYZ= similar to ConditionXYZ=, but fatal for a start job if not met
2014-11-06 13:43:45 +01:00
[JOB_ASSERT] = "assert",
unit: handle nicely of certain unit types are not supported on specific systems Containers do not really support .device, .automount or .swap units; Systems compiled without support for swap do not support .swap units; Systems without kdbus do not support .busname units. With this change attempts to start a unsupported unit types will result in an immediate "unsupported" job result, which is a lot more descriptive then before. Also, attempts to start device units in containers will now immediately fail instead of causing jobs to be enqueued that never go away.
2014-12-12 21:05:32 +01:00
[JOB_UNSUPPORTED] = "unsupported",
core: GC redundant device jobs from the run queue In contrast to all other unit types device units when queued just track external state, they cannot effect state changes on their own. Hence unless a client or other job waits for them there's no reason to keep them in the job queue. This adds a concept of GC'ing jobs of this type as soon as no client or other job waits for them anymore. To ensure this works correctly we need to track which clients actually reference a job (i.e. which ones enqueued it). Unfortunately that's pretty nasty to do for direct connections, as sd_bus_track doesn't work for them. For now, work around this, by simply remembering in a boolean that a job was requested by a direct connection, and reset it when we notice the direct connection is gone. This means the GC logic works fine, except that jobs are not immediately removed when direct connections disconnect. In the longer term, a rework of the bus logic should fix this properly. For now this should be good enough, as GC works for fine all cases except this one, and thus is a clear improvement over the previous behaviour. Fixes: #1921
2016-11-15 19:32:50 +01:00
[JOB_COLLECTED] = "collected",
core: enforce that scope units can be started only once Scope units are populated from PIDs specified by the bus client. We do that when a scope is started. We really shouldn't allow scopes to be started multiple times, as the PIDs then might be heavily out of date. Moreover, clients should have the guarantee that any scope they allocate has a clear runtime cycle which is not repetitive.
2018-04-27 20:35:10 +02:00
[JOB_ONCE] = "once",
dbus: pass along information why a job failed when it failed (dbus api change!)
2011-02-24 02:36:34 +01:00
};
DEFINE_STRING_TABLE_LOOKUP(job_result, JobResult);
core: refactoring: add job_type_to_access_method remove duplication
2016-01-31 14:26:09 +01:00
const char* job_type_to_access_method(JobType t) {
assert(t >= 0);
assert(t < _JOB_TYPE_MAX);
if (IN_SET(t, JOB_START, JOB_RESTART, JOB_TRY_RESTART))
return "start";
else if (t == JOB_STOP)
return "stop";
else
return "reload";
}