f32b43bda454a70ae23d6802605d41b26dc24ce2 |
|
12-Nov-2015 |
Lennart Poettering <lennart@poettering.net> |
core: remove support for RequiresOverridable= and RequisiteOverridable=
As discussed at systemd.conf 2015 and on also raised on the ML:
http://lists.freedesktop.org/archives/systemd-devel/2015-November/034880.html
This removes the two XyzOverridable= unit dependencies, that were
basically never used, and do not enhance user experience in any way.
Most folks looking for the functionality this provides probably opt for
the "ignore-dependencies" job mode, and that's probably a good idea.
Hence, let's simplify systemd's dependency engine and remove these two
dependency types (and their inverses).
The unit file parser and the dbus property parser will now redirect
the settings/properties to result in an equivalent non-overridable
dependency. In the case of the unit file parser we generate a warning,
to inform the user.
The dbus properties for this unit type stay available on the unit
objects, but they are now hidden from usual introspection and will
always return the empty list when queried.
This should provide enough compatibility for the few unit files that
actually ever made use of this. |
6e392c9c45643d106673c6643ac8bf4e65da13c1 |
|
07-Mar-2015 |
Ivan Shapovalov <intelfx100@gmail.com> |
core: do not spawn jobs or touch other units during coldplugging
Because the order of coldplugging is not defined, we can reference a
not-yet-coldplugged unit and read its state while it has not yet been
set to a meaningful value.
This way, already active units may get started again.
We fix this by deferring such actions until all units have been at
least somehow coldplugged.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=88401 |
82a2b6bb5e4e5d294f09af778c48974a7857afb6 |
|
28-Jan-2015 |
Lennart Poettering <lennart@poettering.net> |
core: output unit status output strings to console, only if we actually are changing unit state
Unit _start() and _stop() implementations can fail with -EAGAIN to delay
execution temporarily. Thus, we should not output status messages before
invoking these calls, but after, and only when we know that the
invocation actually made a change. |
c69182961b00707d977957cf81d5c41cfbeab429 |
|
14-May-2012 |
Michal Schmidt <mschmidt@redhat.com> |
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. |