This changes the ProtectSystem= documentation to refer in more explicit
words to the restrictions of ReadOnlyPath=, as sugegsted in #9857.
THis also extends the paragraph in ReadOnlyPath= that explains the hole.
Fixes: #9857
In the documentation for ConditionXYZ= we claimed that AssertXYZ= would
have an effect on unit state (which is wrong), while at the
documentation for AssertXYZ= we said it only has an effect on the job,
but not the unit (which is right). Let's fix this contradiction, and
only claim the latter.
Also, fix a couple of other things (for example, stop talking about a
"failure state", but let's just expressly called it "the 'failed' state",
as that's the actual name of that state.
Finally, let's emphasize again when the conditions/assertions are
executed, and that they hence are not useful to conditionalize deps.
Fixes: #10433
In the default journalctl output, unprintable entries are abbreviated as
“[<amount> blob data]”; using the same term in the documentation helps
users to quickly discover the option they need to add in order to see
those entries.
The &MEMORY_ACCOUNTING_DEFAULT; resolves to "yes" or "no" while the rest
of the paragraph talked about "on" and "off". Let's adjust this and
stick to "yes" and "no"...
Quite frankly I think it's not a particularly good idea to change the
docs based configuration changes... THis can only be incomplete, and the
wording is still very awkward since we repeat the same sentence twice.
This is useful for a couple of cases, I'm mostly interested in case #1:
1. Verifying "reasonable" values in a trivially scriptable way
2. Debugging unexpected time span parsing directly
Test Plan:
```
% build/systemd-analyze timespan 20
Original: 20
μs: 20
Human: 20us
% build/systemd-analyze timespan 20ms
Original: 20ms
μs: 20000
Human: 20ms
% build/systemd-analyze timespan 20z
Failed to parse time span '20z': Invalid argument
```
Add LogRateLimitIntervalSec= and LogRateLimitBurst= options for
services. If provided, these values get passed to the journald
client context, and those values are used in the rate limiting
function in the journal over the the journald.conf values.
Part of #10230
C.f. 287419c119ef961db487a281162ab037eba70c61: 'systemctl exit 42' can be
used to set an exit value and pulls in exit.target, which pulls in systemd-exit.service,
which calls org.fdo.Manager.Exit, which calls method_exit(), which sets the objective
to MANAGER_EXIT. Allow the same to happen through SuccessAction=exit.
v2: update for 'exit' and 'exit-force'
We would accept e.g. FailureAction=reboot-force in user units and then do an
exit in the user manager. Let's be stricter, and define "exit"/"exit-force" as
the only supported actions in user units.
v2:
- rename 'exit' to 'exit-force' and add new 'exit'
- add test for the parsing function
FailureAction=/SuccessAction= were added later then StartLimitAction=, so it
was easiest to refer to the existing description. But those two settings are
somewhat simpler (they just execute the action unconditionally) while
StartLimitAction= has additional timing and burst parameters, and they are
about to take on a more prominent role, so let's move the description of
allowed values.
The term “positive” is often read to exclude 0 (though “strictly
positive” is sometimes used to clarify this), so let’s explicitly state
that --lines=0 is legal and completely disables journal output.
Motivated by an answer on StackExchange [1].
[1]: https://unix.stackexchange.com/a/475068/44049
These man pages list references to the various sd_event_add_xyz() calls
at the bottom, but sd_event_add_inotify() was never added there.
Moreover, some list references to sd_event_add_post() and
sd_event_add_exit() even though these have shared man pages with
sd_event_add_defer(), and given that the "SEE ALSO" section should
probably reference pages instead of functions let's drop this.
Then, let's always specify the sd_event_add_xyz() calls in the same
order.
Finally, in the sd_event_new(3) text explaining the basic logic,
actually mention sd_event_add_post() and sd_event_add_exit() as well, as
in that case we actually want to list functions, not man pages.
Also, while we are at it, beef it up, by adding json-seq support (i.e.
https://tools.ietf.org/html/rfc7464). This is particularly useful in
conjunction with jq's --seq switch.
