| Age | Commit message (Collapse) | Author |
|---|
|
|
|
first (or second)
Previously the returned object of constructor functions where sometimes
returned as last, sometimes as first and sometimes as second parameter.
Let's clean this up a bit. Here are the new rules:
1. The object the new object is derived from is put first, if there is any
2. The object we are creating will be returned in the next arguments
3. This is followed by any additional arguments
Rationale:
For functions that operate on an object we always put that object first.
Constructors should probably not be too different in this regard. Also,
if the additional parameters might want to use varargs which suggests to
put them last.
Note that this new scheme only applies to constructor functions, not to
all other functions. We do give a lot of freedom for those.
Note that this commit only changes the order of the new functions we
added, for old ones we accept the wrong order and leave it like that.
|
|
|
|
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.
|
|
This reverts commit 2cba2e03524ec0922ddc70f933e8a89b7d23b4ec.
It breaks bootup with dracut, the transition to the real rootfs fails.
|
|
|
|
Produces output like:
[ *** ] (1 of 2) A start job is running for slow.service (33s / 1min 30s)
The first nubmer is the time since job start, the second is the job timeout.
|
|
Things will continue when either the job timeout
or the unit timeout is reached. Add functionality to
access that info.
|
|
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.
|
|
Clang is a bit more strict wrt format-nonliterals:
http://clang.llvm.org/docs/LanguageExtensions.html#format-string-checking
Adding these extra printf attributes also makes gcc able to find more
problems. E.g. this patch uncovers a format issue in udev-builtin-path_id.c
Some parts looked intetional about breaking the format-nonliteral check.
I added some supression for warnings there.
|
|
systemctl reload "suceeded" on stopped units, but it is documented
to fail in this case.
https://bugzilla.redhat.com/show_bug.cgi?id=1036845
|
|
|
|
Always read all external events before we decide what we do next.
|
|
|
|
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.
|
|
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.
|
|
"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.
|
|
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.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=68232
|
|
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.
|
|
I'm assuming that it's fine if a _const_ or _pure_ function
calls assert. It is assumed that the assert won't trigger,
and even if it does, it can only trigger on the first call
with a given set of parameters, and we don't care if the
compiler moves the order of calls.
|
|
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.
|
|
Before, we would initialize many fields twice: first
by filling the structure with zeros, and then a second
time with the real values. We can let the compiler do
the job for us, avoiding one copy.
A downside of this patch is that text gets slightly
bigger. This is because all zero() calls are effectively
inlined:
$ size build/.libs/systemd
text data bss dec hex filename
before 897737 107300 2560 1007597 f5fed build/.libs/systemd
after 897873 107300 2560 1007733 f6075 build/.libs/systemd
… actually less than 1‰.
A few asserts that the parameter is not null had to be removed. I
don't think this changes much, because first, it is quite unlikely
for the assert to fail, and second, an immediate SEGV is almost as
good as an assert.
|
|
The "OK" status messages should not draw attention to themselves.
It's better if they're not printed in bright/bold. Leave that
to errors and warnings.
Use a plain inconspicuous enterprisey green.
|
|
Ephemeral status lines do not end with a newline and they expect to be
overwritten by the next printed status line.
|
|
Take advantage of the fact that almost all callers want to pass unit
description as the last parameter. Those who don't can use the more
flexible manager_status_printf().
|
|
|
|
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.
|
|
|
|
This fixes a bug where a job with --ignore-dependencies would wait for
other jobs because it merged into a previously queued job.
|
|
|
|
|
|
|
|
I hit an "assert(j->installed)" failure in transaction_apply(). Looking
into the backtrace I saw what happened:
1. The system was booting. var.mount/start was an installed job.
2. I pressed Ctrl+Alt+Del.
3. reboot.target was going to be isolated.
4. transaction_apply() proceeded to install a var.mount/stop job.
5. job_install() canceled the conflicting start job.
6. Depending jobs ended recursively with JOB_DEPENDENCY, among them was
local-fs.target/start.
7. Its OnFailure action triggered - emergency.target was now going to be
isolated.
8. We recursed back into transaction_apply() where the half-installed
var.mount/stop job confused us.
Recursing from job installation back into the transaction code cannot be
a good idea. Avoid the problem by canceling the conflicting job
non-recursively in job_install(). I don't think we'll miss anything by
not recursing here. After all, we are called from transaction_apply().
We will not be installing just this one job, but all jobs from a
transaction. All requirement dependencies will be included in it and
will be installed separately. Every transaction job will get a chance
to cancel its own conflicting installed job.
|
|
The MESSAGE_ID=... stanza will appear in countless number of places.
It is just too long to write it out in full each time.
Incidentally, this also fixes a typo of MESSSAGE is three places.
|
|
|
|
|
|
|
|
|
|
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.
|
|
The red "[ABORT]" for a dependency failure is too scary.
It suggests a crash. And it suggests a problem with the unit itself.
Change it to a yellow "[DEPEND]" message. The color communicates the
level of seriousness better.
|
|
|
|
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
|
|
Recursive cancellation of jobs would trigger OnFailure actions of
dependent jobs. This is not desirable when isolating.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=798328
|
|
Jobs were not preserved correctly over a daemon-reload operation.
A systemctl process waiting for a job completion received a job removal
signal. The job itself changed its id. The job timeout started ticking all
over again.
This fixes the deficiencies.
|
|
|
|
Merging of jobs can result in more than one client being interested in a job.
|
|
Transactions cannot contain installed jobs anymore. Remove the now pointless
checks.
|
|
Previously transactions could reference installed jobs. It made some issues
difficult to fix.
This sets new rules for jobs:
A job cannot be both a member of a transaction and installed. When jobs are
created, they are linked to a transaction. The whole transaction is constructed
(with merging of jobs within, etc.). When it's complete, all the jobs are
unlinked from it one by one and let to install themselves. It is during the
installation when merging with previously installed jobs (from older
transactions) is contemplated.
Merging with installed jobs has different rules than merging within a
transaction:
- An installed conflicting job gets cancelled. It cannot be simply deleted,
because someone might be waiting for its completion on DBus.
- An installed, but still waiting, job can be safely merged into.
- An installed and running job can be tricky. For some job types it is safe to
just merge. For the other types we merge anyway, but put the job back into
JOB_WAITING to allow it to run again. This may be suboptimal, but it is not
currently possible to have more than one installed job for a unit.
Note this also fixes a bug where the anchor job could be deleted during merging
within the transaction.
|
|
Let the jobs install themselves.
|
