In certain cases the expected enqueue-start-replace-continue
sequence would end up as enqueue-replace-start-continue which causes
unexpected fails even though the serialization/deserialization part
works as expected. As we can't use `--wait` in this case, let's give
sysetmd a second to actually start the unit before replacing it with
another one.
Also, switch from the single-letter test output to a bit verbose format.
Fixes: #14632
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
This commit fixes crash described in
https://github.com/systemd/systemd/issues/6533
Multiple ExecStart lines are allowed only for oneshot services
anyway so it doesn't make sense to call service_run_next_main() with
services of type other than SERVICE_ONESHOT.
Referring back to reproducer from the issue, previously we didn't observe
this problem because s->main_command was reset after daemon-reload hence
we never reached the assert statement in service_run_next_main().
Fixes#6533
This is useful on systems like NixOS, where python3 is not in
/usr/bin/python3 as well as for people using alternative ways to
install python such as virtualenv/pyenv.
Yu Watanabe