bus_unit_queue_job_one has two callers:
- bus_unit_queue_job which would do the appropriate transormations
to turn JOB_TRY_RESTART into JOB_TRY_RELOAD,
- and method_enqueue_marked_jobs which did not.
In effect, method_enqueue_marked_jobs() would queue restart jobs for
units which has Markers= needs-reload or needs-restart.
When the chunk of code which does the transformations is moved from
bus_unit_queue_job to bus_unit_queue_job_one, there is no change for
bus_unit_queue_job, and method_enqueue_marked_jobs is fixed.
The additional checks that are done seem reasonable to do from
method_enqueue_marked_jobs: we shouldn't be restarting units which are
configured to not allow that, or force unwanted start of dbus-broker.
manager_{get|set|override}_watchdog check the validity of the new
timeout or the overridden timeout values using timestamp_is_set which
does not recognize "0" as a valid value. However since f16890f, "0"
indicates a disabled watchdog and so is a value we should be able to
configure in order to disable the watchdog. A value of USEC_INFINITY is
considered a no-op. The behavior should be the same for all watchdog
timeout configurations (runtime, pretimeout, and shutdown).
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_PRIVILEGE() are the values
returned by set_oom_score_adjust() and set_coredump_filter() which are
not expected to return any positive values, but let's be consistent
anyway and move the ERRNO_IS_PRIVILEGE() invocations to the branches
where the return values are known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the
value returned by varlink_connect_address() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_DISCONNECT() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_DISCONNECT() are the
values returned by instance_from_socket(), socket_load_service_unit(),
and service_set_socket_fd() which are not expected to return any
positive values, but let's be consistent anyway and move
ERRNO_IS_DISCONNECT() invocations to the branches where the return
values are known to be negative.
As it says on the tin, configures the unit to survive a soft reboot.
Currently all the following options have to be set by hand:
Conflicts=reboot.target kexec.target poweroff.target halt.target
Before=reboot.target kexec.target poweroff.target halt.target
After=sysinit.target basic.target
DefaultDependencies=no
IgnoreOnIsolate=yes
This is not very user friendly. If new default dependencies are added,
or new shutdown/reboot types, they also have to be added manually.
The new option is much simpler, easy to find, and does the right thing
by default.
Currently for portable services we automatically add a bind mount
os-release -> /run/host/os-release. This becomes problematic for the
soft-reboot case, as it's likely that portable services will be configured
to survive it, and thus would forever keep a reference to the old host's
os-release, which would be a problem because it becomes outdated, and also
it stops the old rootfs from being garbage collected.
Create a copy when the manager starts under /run/systemd/propagate instead,
and bind mount that for all services using RootDirectory=/RootImage=, so
that on soft-reboot the content gets updated (without creating a new file,
so the existing bind mounts will see the new content too).
This expands the /run/host/os-release protocol to more services, but I
think that's a nice thing to have too.
Closes https://github.com/systemd/systemd/issues/28023
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the value
returned by socket_acquire_peer() which can legitimately return 1
without errno semantics, so fix this by moving ERRNO_IS_DISCONNECT()
invocation to the branch where the return value is known to be negative.
This commit allows service_sigchld_event() is executed before
service_dispatch_exec_io(), which might happen when a main process exits
very quickly.
Also do not check PID for service goodness because the main process have
already been exited in this case.
Fix: #27919
When systemd-firstboot (or any other unit which uses the tty) is started,
systemd will reset the terminal. If systemd-vconsole-setup happens to be
running at that time, it'll error out when it tries to use the vconsole fd and
gets an EIO from ioctl.
e019ea738d was the first fix. It added an
implicit ordering between units using the tty and systemd-vconsole-setup.
(The commit title is wrong. The approach was generalized, but the commit title
wasn't updated.)
Then cea32691c3 was added to restart
systemd-vconsole-setup.service from systemd-firstboot.service. This was OK,
with the ordering in place, systemd-vconsole-setup.service would wait until
systemd-firstboot.service exited. But this wasn't enough, because we want the
key mappings to be loaded immediately after systemd-firstboot writes the
config. 8eb668b9ab implemented that, but actually
reintroduced the original issue. I had to drop the ordering between the two
units because otherwise we'd deadlock, waiting from firstboot for
vconsole-setup which wouldn't start while firstboot was running.
Restarting vconsole-setup.service from systemd-firstboot.service works just
fine, but when vconsole-setup.service is started earlier, it may be interrupted
by systemd-firstboot.service.
To resolve the issue, let's take a lock around the tty device. The reset is
performed after fork, so the (short) delay should not matter too much.
In xopenat_lock() the assert on <path> is dropped so that we can call
xopenat(fd, NULL) to get a copy of the original fd.
Fixes#26908.
Follow-up for 2a39b91459
The mentioned change makes all jobs in the transaction unmergeable
if mode == JOB_RESTART_DEPENDENCIES, but we only want the anchor job
to be re-enqueued.
This reverts commit e019ea738d.
In the new approach, a lock on /dev/console will be used. This lock will solve
the issue for services which run in early boot. Services which run later are
ordered after sysinit.target, so they'll run much later anyway so this
automatic dependency is not useful. Let's remove it again to make the code
simpler.
When there is no access to cgroups MANAGER_TEST_RUN_BASIC will fail
to set up and assert. This happens on a build system like Debian's.
Switch to _MINIMAL which skips cgroup and other machine-wide setups.
With the fix done in PR28215, the unit restart job is created with type JOB_START.
Because of that, it is not properly merged anymore with the old one: the
merged job has state JOB_RUNNING. It should have state JOB_WAITING.
I think that the old job is not cleaned up because we don't go through the failed state.
With this fix, the merged job is properly created with state JOB_WAITING.
When this option is set to direct, the service restarts without entering a failed
state. Dependent units are not notified of transitory failure.
This is useful for the following use case:
We have a target with Requires=my-service, After=my-service.
my-service.service is a oneshot service and has Restart=on-failure in
its definition.
my-service.service can get stuck for various reasons and time out, in
which case it is restarted. Currently, when it fails the first time, the
target fails, even though my-service is restarted.
The behavior we're looking for is that until my-service is not restarted
anymore, the target stays pending waiting for my-service.service to
start successfully or fail without being restarted anymore.
Let's cast these floats explicitly to usec_t, since implicit
float-to-integer casts are dangerous business, and we should underline
that there's a cast happening here.
Follow-up for 017a7ba4f4
Before this commit, when a unit that is restarting propagates stop
to other units, it can also depend on them, which results in
job type conflict and thus failure to pull in the dependencies.
So, let's introduce a new dependency atom UNIT_ATOM_PROPAGATE_STOP_GRACEFUL,
and use it for PropagatesStopTo=. It will enqueue a restart job if
there's already a start job, which meets the ultimate goal and avoids
job type conflict.
Fixes#26839
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Khem Raj
David Tardon
Curtis Klein
Luca Boccassi
Dmitry V. Levin
Frantisek Sumsal
Daan De Meyer
Fuminobu TAKEYAMA
Mike Yuan
Lennart Poettering
Richard Phibel
Daniel P. Berrangé