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
This reverts the primary effect of be7d9ff730.
After all Requisite= should be close to Requires=, without the one
exception that it doesn't pull in dependencies on start. However,
reverse deps on stop/restart should be treated the same way as for
Restart=, and this is already documented in the man page, hence stick to
it.
http://lists.freedesktop.org/archives/systemd-devel/2015-May/032049.html
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
This is yet another attempt to fix coldplugging order (more especially,
the problem which happens when one creates a job during coldplugging and
it references a not-yet-coldplugged unit).
Now we forcibly coldplug all units which participate in jobs. This
is a superset of previously implemented handling of the UNIT_TRIGGERS
dependencies, so that handling is removed.
http://lists.freedesktop.org/archives/systemd-devel/2015-April/031212.htmlhttps://bugs.freedesktop.org/show_bug.cgi?id=88401 (once again)
This patch removes includes that are not used. The removals were found with
include-what-you-use which checks if any of the symbols from a header is
in use.
As a followup to 086891e5c1 "log: add an "error" parameter to all
low-level logging calls and intrdouce log_error_errno() as log calls
that take error numbers", use sed to convert the simple cases to use
the new macros:
find . -name '*.[ch]' | xargs sed -r -i -e \
's/log_(debug|info|notice|warning|error|emergency)\("(.*)%s"(.*), strerror\(-([a-zA-Z_]+)\)\);/log_\1_errno(-\4, "\2%m"\3);/'
Multi-line log_*() invocations are not covered.
And we also should add log_unit_*_errno().
- Rename log_meta() → log_internal(), to follow naming scheme of most
other log functions that are usually invoked through macros, but never
directly.
- Rename log_info_object() to log_object_info(), simply because the
object should be before any other parameters, to follow OO-style
programming style.
The previous fix e0312f4db "core: fix check for transaction
destructiveness" broke test-engine (noticed by Zbyszek).
Apparently I had a wrong idea of the intended semantics of --fail.
The manpage says the operation should fail if it "conflicts with a
pending job (more specifically: causes an already pending start job to
be reversed into a stop job or vice versa)".
So let's check job_type_is_conflicting, instead of !is_superset.
This makes both test-engine and TEST-03-JOBS pass again.
When checking if the transaction is destructive, we need to check if the
previously installed job is a superset of the new job (and hence the new
job will fold into the installed one without changing it), not the other
way around.
This way they always show up together with 'Found ordering cycle...'.
Ordering cycles are a serious error and a major pain to debug. If
quiet is enabled, only the first and the last line of output are
shown:
systemd[1]: Found ordering cycle on basic.target/start
systemd[1]: Breaking ordering cycle by deleting job timers.target/start
systemd[1]: Job timers.target/start deleted to break ordering cycle starting with basic.target/start
which isn't particularly enlightening. So just show the whole message
at the same level.
https://bugzilla.redhat.com/show_bug.cgi?id=1158206
It is redundant to store 'hash' and 'compare' function pointers in
struct Hashmap separately. The functions always comprise a pair.
Store a single pointer to struct hash_ops instead.
systemd keeps hundreds of hashmaps, so this saves a little bit of
memory.
Patch fixes some incorrect-looking code in transaction.c.
It could fix cases where Debian users with bad package configurations
had systemd go into an infinite loop printing messages about breaking an
ordering cycle, though I have not reproduced that problem myself.
transaction_verify_order_one() considers jobs/units outside current
transaction when checking whether ordering dependencies cause cycles.
It would also incorrectly try to break cycles at these jobs; this
cannot work, as the break action is to remove the job from the
transaction, which is a no-op if the job isn't part of the transaction
to begin with. The unit_matters_to_anchor() test also looks like it
would not work correctly for non-transaction jobs. Add a check to
verify that the unit is part of the transaction before considering a
job a candidate for deletion.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752259
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.
Make Type=idle communication bidirectional: when bootup is finished,
the manager, as before, signals idling Type=idle jobs to continue.
However, if the boot takes too long, idling jobs signal the manager
that they have had enough, wait a tiny bit more, and continue, taking
ownership of the console. The manager, when signalled that Type=idle
jobs are done, makes a note and will not write to the console anymore.
This is a cosmetic issue, but quite noticable, so let's just fix it.
Based on Harald Hoyer's patch.
https://bugs.freedesktop.org/show_bug.cgi?id=54247http://unix.stackexchange.com/questions/51805/systemd-messages-after-starting-login/
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.
Like other status messages, this one too should not be printed
unconditionally, but it should take the manager state into account.
unit_status_printf() does that.
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.
Having unit(s) removed/not started, even if it solved the issue and allowed
to boot successfully, should still be considered an error, as something
clearly isn't right.
This patch elevates the log message from warning to error, and adds a status
message to make things more obvious.
This should address TODO item "new dependency type to "group" services
in a target". Semantic of new dependency is as follows. Once configured
it creates dependency which will cause that all dependent units get
stopped if unit they all depend on is stopped or restarted. Usual use
case would be configuring PartOf=some.target in template unit file
and WantedBy=some.target in [Install] section and enabling desired
number of instances. In this case starting one instance won't pull in
target but stopping or starting target(in case of WantedBy is properly
configured) will cause stop/start of all instances.
all other dependencies are in 3rd person. Change BindTo= accordingly to
BindsTo=.
Of course, the dependency is widely used, hence we parse the old name
too for compatibility.
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
Type=idle is much like Type=simple, however between the fork() and the
exec() in the child we wait until PID 1 informs us that no jobs are
left.
This is mostly a cosmetic fix to make gettys appear only after all boot
output is finished and complete.
Note that this does not impact the normal job logic as we do not delay
the completion of any jobs. We just delay the invocation of the actual
binary, and only for services that otherwise would be of Type=simple.
Recursion is unnecessary, because we're deleting all transaction jobs
anyway. And the recursive deletion produces debug messages that are
pointless in transaction abort.
A transaction can be acyclic, but when it's added to installed jobs,
a cycle may result.
transaction_verify_order_one() attempts to detect these cases, but it
fails because the installed jobs often have the exact generation number
that makes them look as if they were walked already.
Fix it by resetting the generation numbers of all installed jobs before
detecting cycles.
An alternative fix could be to add the generation counter to the
Manager and use it instead of starting always from 1 in
transaction_activate(). But I prefer not having to worry about it
wrapping around.
The functions looked complicated with the nested loops with breaks,
continues, and "while (again)".
Here using goto actually makes them easier to understand.
Also correcting the comment about redundant jobs.
While having a Requires= dependency between units, the dependency is started
automatically on "systemctl start", but it's not started on "systemctl
restart".
JOB_RESTART jobs did not pull the dependencies for starting into the
transaction.
https://bugzilla.redhat.com/show_bug.cgi?id=802770
Note that the other bug noted in comment #2 has been fixed already by avoiding
the deletion of anchor jobs.
