This renames wait_for_terminate_and_warn() to
wait_for_terminate_and_check(), and adds a flags parameter, that
controls how much to log: there's one flag that means we log about
abnormal stuff, and another one that controls whether we log about
non-zero exit codes. Finally, there's a shortcut flag value for logging
in both cases, as that's what we usually use.
All callers are accordingly updated. At three occasions duplicate logging
is removed, i.e. where the old function was called but logged in the
caller, too.
This adds a new safe_fork() wrapper around fork() and makes use of it
everywhere. The new wrapper does a couple of things we previously did
manually and separately in a safer, more correct and automatic way:
1. Optionally resets signal handlers/mask in the child
2. Sets a name on all processes we fork off right after forking off (and
the patch assigns useful names for all processes we fork off now,
following a systematic naming scheme: always enclosed in () – in order
to indicate that these are not proper, exec()ed processes, but only
forked off children, and if the process is long-running with only our
own code, without execve()'ing something else, it gets am "sd-" prefix.)
3. Optionally closes all file descriptors in the child
4. Optionally sets a PR_SET_DEATHSIG to SIGTERM in the child, in a safe
way so that the parent dying before this happens being handled
safely.
5. Optionally reopens the logs
6. Optionally connects stdin/stdout/stderr to /dev/null
7. Debug logs about the forked off processes.
Followup to previous commit. Suggested by @poettering.
Reindented the `verbs[]` tables to match the apparent previous
whitespace rules (indent to one flag, allow multiple flags to overflow?).
A lot of code references the `running_in_chroot()` function; while
I didn't dig I'm pretty certain this arose to deal with situations
like RPM package builds in `mock` - there we don't want the `%post`s
to `systemctl start` for example.
And actually this exact same use case arises for
[rpm-ostree](https://github.com/projectatomic/rpm-ostree/)
where we implement offline upgrades by default; the `%post`s are
always run in a new chroot using [bwrap](https://github.com/projectatomic/bubblewrap).
And here's the problem: bwrap creates proper mount roots, so it
passes `running_in_chroot()`, and then if a script tries to do
`systemctl start` we get:
`System has not been booted with systemd as init system (PID 1)`
but that's an *error*, unlike the `running_in_chroot()` case where we ignore.
Further complicating things is there are real world RPM packages
like `glusterfs` which end up invoking `systemctl start`.
A while ago, the `SYSTEMD_IGNORE_CHROOT` environment variable was
added for the inverse case of running in a chroot, but still wanting
to use systemd as PID 1 (presumably some broken initramfs setups?).
Let's introduce a `SYSTEMD_OFFLINE` environment variable for cases like
mock/rpm-ostree so we can force on the "ignore everything except preset" logic.
This way we'll still not start services even if mock switches to use nspawn or
bwrap or something else that isn't a chroot.
We also cleanly supercede the `SYSTEMD_IGNORE_CHROOT=1` which is now spelled
`SYSTEMD_OFFLINE=0`. (Suggested by @poettering)
Also I made things slightly nicer here and we now print the ignored operation.
This renames find_esp() to find_esp_and_warn() and tries to normalize its
behaviour:
1. Change the error that is returned when we can't find the ESP to
ENOKEY (from ENOENT). This way the error code can only mean one
thing: that our search loop didn't find a good candidate.
2. Really log about all errors, except for ENOKEY and EACCES, and
document the letter cases.
3. Normalize parameters to the call: separate out the path parameter in
two: an input path and an output path. That way the memory management
is clear: we will access the input parameter only for reading, and
only write out the output parameter, using malloc() memory.
Before the calling convention were quire surprising for internal API
code, as the path parameter had to be malloc() memory and might and
might not have changed.
4. Rename bootctl's find_esp_warn() to acquire_esp(), and make it a
simple wrapper around find_esp_warn(), that basically just adds the
friendly logging for the ENOKEY case. This rework removes double
logging in a number of error cases, as we no longer log here in
anything but ENOKEY, and leave that entirely to find_esp_warn().
5. find_esp_and_warn() now takes a bool flag parameter
"unprivileged_mode", which disables logging in the EACCES case, and
skips privileged validation of the path. This makes the function less
magic, and doesn't hide this internal silencing automatism from the
caller anymore.
With all that in place "bootctl list" and "bootctl status" work properly
(or as good as they can) when I invoke the tools whithout privileges on
my system where /boot is not world-readable
Let's not use local process data for remote processes, that can only
show nonsense.
Maybe one day we should add a bus API to query the comm field of a
process remotely, but for now, let's not bother, the information is
redundant anyway, as the cgroup data shows it too (and the cgroup tree
is show as part of status as well, and is requested from remote through
dbus, without local kernel calls).
Fixes: #7516
This message is displayed either when the unit file itself is newer than
what is loaded, but also when any of the drop-ins is newer. Say so in
the message, in order not to confuse the user unnecessarily.
We should not only ignore "-t" itself, but also whatever is passed to
it.
This pretty much reverts the core of
a4420f7b8e, and adds back in the status
quo ante. What a difference a ':' can make.
This also adds a quick comment for this, so that we don't make this
mistake again.
Fixes: #7413
We just load the same kernel that would be loaded by default by sd-boot, with
the same options. Changing the kernel or initramfs or options is left for
later.
Now we will refuse to continue if loading fails. This makes 'systemctl kexec'
more predictable: it will not fall back to normal reboot if the kernel is
not loaded.
Both permit configuring data to pass through STDIN to an invoked
process. StandardInputText= accepts a line of text (possibly with
embedded C-style escapes as well as unit specifiers), which is appended
to the buffer to pass as stdin, followed by a single newline.
StandardInputData= is similar, but accepts arbitrary base64 encoded
data, and will not resolve specifiers or C-style escapes, nor append
newlines.
This may be used to pass input/configuration data to services, directly
in-line from unit files, either in a cooked or in a more raw format.
loginctl, machinectl, systemctl all have very similar implementations of
a get_output_flags() functions. Simplify it by merging two lines that
set the same flag.
Currently, "systemctl reboot" behaves differently in setups with and
without logind. If logind is used (which is probably the more common
case) the operation is asynchronous, and otherwise synchronous (though
subject to --no-block in this case). Let's clean this up, and always
expose the same behaviour, regardless if logind is used or not: let's
always make it asynchronous.
It might make sense to add a "--block" mode in a future PR that makes
these operations synchronous, but this requires non-trivial work in
logind, and is outside of the scope of this change.
See: #6479
This adds new method calls Halt() and CanHalt() to the logind bus APIs.
They aren't overly useful (as the whole concept of halting isn't really
too useful), however they clean up one major asymmetry: currently, using
the "shutdown" legacy commands it is possibly to enqueue a "halt"
operation through logind, while logind officially doesn't actually
support this. Moreover, the path through "shutdown" currently ultimately
fails, since the referenced "halt" action isn't actually defined in
PolicyKit.
Finally, the current logic results in an unexpected asymmetry in
systemctl: "systemctl poweroff", "systemctl reboot" are currently
asynchronous (due to the logind involvement) while "systemctl halt"
isnt. Let's clean this up, and make all three APIs implemented by
logind natively, and all three hence asynchronous in "systemctl".
Moreover, let's add the missing PK action.
Fixes: #6957
This was the one valid site in commit
ee043777be.
The second part of this hunk, avoiding using `%m`
when we didn't actually have `errno` set, seems
like a nice enough cleanup to be worthwhile on
it's own.
Also use PID_FMT to improve the error message we print
(pid_t is signed).
The advantage is that is the name is mispellt, cpp will warn us.
$ git grep -Ee "conf.set\('(HAVE|ENABLE)_" -l|xargs sed -r -i "s/conf.set\('(HAVE|ENABLE)_/conf.set10('\1_/"
$ git grep -Ee '#ifn?def (HAVE|ENABLE)' -l|xargs sed -r -i 's/#ifdef (HAVE|ENABLE)/#if \1/; s/#ifndef (HAVE|ENABLE)/#if ! \1/;'
$ git grep -Ee 'if.*defined\(HAVE' -l|xargs sed -i -r 's/defined\((HAVE_[A-Z0-9_]*)\)/\1/g'
$ git grep -Ee 'if.*defined\(ENABLE' -l|xargs sed -i -r 's/defined\((ENABLE_[A-Z0-9_]*)\)/\1/g'
+ manual changes to meson.build
squash! build-sys: use #if Y instead of #ifdef Y everywhere
v2:
- fix incorrect setting of HAVE_LIBIDN2
This reverts commit ee043777be.
It broke almost everywhere it touched. The places that
handn't been converted, were mostly followed by special
handling for the invalid PID `0`. That explains why they
tested for `pid < 0` instead of `pid <= 0`.
I think that one was the first commit I reviewed, heh.
systemctl would try to load the properties of the unit, which is impossible
for template names, and the whole operation would fail. It seems that this
regression was introduced in 00c83b4300.
Export the part of unit_find_paths() responsible for locating instance unit
fragments and reuse it from unit_exists() to fix the handling of template
units.
Fixes#6412.
913c1916 changed _ACTION_INVALID to negative, changing the enum to a
signed type. Take care to avoid comparing it with an unsigned type.
../src/systemctl/systemctl.c: In function ‘start_unit’:
../src/systemctl/systemctl.c:3107:35: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
assert(arg_action < ELEMENTSOF(action_table));
start_unit() is a little tangled. There's an easy part we can untangle,
then readers can concentrate on the more necessary complexity.
* Derive (method, action, mode) more clearly, as disjoint cases based on
the command. Don't rely on action_table[_ACTION_INVALID].target being
implicitly initialized to NULL.
verb_to_method() is now only used on one case, but not because I strongly
object to the implicit "StartUnit" cases. It's more a syntax problem.
I think the old code takes me longer to understand, because the call
comes just above a similar-looking call to verb_to_action(), but the
results of the two functions are used in different ways. It also helps
that the new code ends up having a more regular form, for the 4 different
cases.
These changes cost 6 extra lines.
* Add an assertion to confirm that we do not pass mode=NULL.
ACTION_EMERGENCY and ACTION_DEFAULT would be handled correctly by
start_with_fallback(). However there is no fallback available for
them, and they would never be set in `arg_action` in the first
place. Remove the unused cases from the switch statement.
@poettering suggested this makes a good place to clarify the point,
explicitly listing all the `arg_action` values which would never be
set.
There's no good reason to use `--wait` with ReloadOrRestartUnit, or
TryRestartUnit.
The message was also wrong in another sense. 'systemctl isolate'
starts units, but it did not support `--wait`. Although it's
unlikely anyone would want to do that in the first place.
