If you're using `udevadm monitor` from a script, without a tty, then
libc defaults to being fully-buffered, and won't flush stdout after
newlines. This is fine for tools that dump a bunch of data and then
exit immediately. It's a problem for tools like `udevadm monitor` which
have long pauses: the buffered data can get stuck in the buffer for an
unbounded amount of time.
In the Cockpit project we've been working around this for some time with
`stdbuf` which is a `LD_PRELOAD` hack to change the libc buffering
behaviour, but we'd like to stop doing that.
Let's make sure we flush the buffer after each event.
As 'systemctl stop' is called with --no-block, previously systemd-resolved
might not be stopped when 'resolvectl' is called, and the DBus connection
might be closed during the call:
```
TEST-07-PID1.sh[5643]: + systemctl stop --no-block systemd-resolved.service
TEST-07-PID1.sh[5643]: + resolvectl
TEST-07-PID1.sh[5732]: Failed to get global data: Remote peer disconnected
```
Follow-up for 8eefd0f4de.
Fixes https://github.com/systemd/systemd/pull/39388#issuecomment-3439277442.
So even if a <term> section contains newlines, we get a reasonable
anchor link to it.
Before:
```
<dt id="
bind
UNIT
PATH
[PATH]
"><span class="term">
...
<a class="headerlink" title="Permalink to this term" href="#%0A%20%20%20%20%20%20%20%20%20%20%20%20bind%0A%20%20%20%20%20%20%20%20%20%20%20%20UNIT%0A%20%20%20%20%20%20%20%20%20%20%20%20PATH%0A%20%20%20%20%20%20%20%20%20%20%20%20[PATH]%0A%20%20%20%20%20%20%20%20%20%20">¶</a>
```
After:
```
<dt id="bind UNIT PATH [PATH]"><span class="term">
...
<a class="headerlink" title="Permalink to this term" href="#bind%20UNIT%20PATH%20[PATH]">¶</a>
```
Resolves: https://github.com/systemd/systemd/issues/39196
---
The reverts are not strictly necessary here (as already pointed out in
https://github.com/systemd/systemd/pull/39154#issuecomment-3360118164)
but they were helpful in checking if the fix works as expected. I can
drop them if needed.
Otherwise, we may not get stacktrace of the crashed process when it is
in running a mount namespace, especially when it is in a portable
service or service that uses RootImage=/RootDirectory=.
- Renames Context to CoredumpContext.
- Renames enum meta_argv_t to MetadataField, and use the correct type at
several pleaces, especially in loop.
- Parses argv (when invoked as kernel helper or with '--backtrace') or
iov (when invoked through socket) and store values in the context.
Previously we use the passed string as is, but let's make them in a
type safe way.
- Stores received or built iovw in the context. Also store input fd and
mountfs fd in the context.
- Introduces coredump_context_is_pid1() and _is_journald() helper
functions.
- Adds COREDUMP_PIDFDID= field when the kernel passed pidfd of the
crashed process.
No effective funtional change. Just refactoring.
When running as backtrace mode, it is not necessary to use kmsg, not
necessary to disable coredump from the command, and unexpectedly
passed file descriptors can be silently ignored.
- introduce CoredumpConfig object that stores all configuration
parameters parsed from coredump.conf,
- use gperf to generate conf parser table,
- parse coredump.conf only when necessary: when systemd-coredump is
invoked as kernel helper or by socket actiavation.
The DBUS_SESSION_BUS_ADDRESS and DBUS_SYSTEM_BUS_ADDRESS parameters have
an interesting syntax thats useful to complete. Let's include a
completion definition for these parameters.
People make weird assumptions around state preservation and
expect logind to be stoppable. While this is realistically
not OK we can probably improve things a little.
This complements f01d8658a3 and
adds support for deserializing the LEADER_PIDFDID= field.
We still prioritize pidfd if got one from fdstore (as with
service_notify_message_parse_new_pid() in pid1), but otherwise
this should make logind restart more robust when fdstore
gets spuriously cleared.
Fixes#39437
Previously, we limit the length of process name by 8.
This relax the restriction then at least process comm or
program_invocation_name contains the untrucated process name.
Closes#38367.
As the modified service requires about ~10 seconds for stopping, the
service never hit the start limit even if we tried to restart the
service more than 5 times.
This also checks that the service is actually triggered by dbus method
call.
Follow-up for 8eefd0f4de.
Check whether the argument of the `--background` option of
`systemd-run`, `run0`, `systemd-nspawn`, `systemd-vmspawn`, and
`systemd-pty-forward` is either empty or looks like an ANSI color code,
and reject invalid values when parsing arguments.
We consider a string to look like an ANSI color code if it consists of
one or more sequences of ASCII digits separated by semicolons. This
permits every valid ANSI color code, and should reject anything that
results in garbled output.