When journald reaches the maximum number of active streams, it,
basically, starts to decline new connections. On the client
side it can be detected by getting EPIPE and, if the writing
process isn't lucky enough, getting SIGPIPE soon afterwards.
systemd has always ignored EPIPE, which makes it very hard
to keep track of services losing logs. This patch should make
it easier to detect such services by just staring at the logs
carefully.
In case anyone is interested, the following one-liner run as any user
can be used to paralyze all the stream logging on a machine:
for i in {1..4096}; do systemd-cat -t HEY-$i & done
tests: clean up again after running tests (#10446)
Currently, if I run the full "run-integration-tests.sh" script it will
fail on my machine because it fills up /var/tmp whith just too much
crap until the disk is full.
Let's make sure that "run-integration-tests.sh" cleans up after every
test. For that change the make targets to run from "clean setup run" to
"clean setup run clean" — except that that doesn't work since make is
smart enough to realize that the same target appears twice on the
command line and will only execute it once. Let's fix that by defining
another target "clean-again" which is just like "clean", but allows us
to be added to the same command line a second time. Then, let's build
with "clean setup run clean-again" and all is good.
While we are at it, let's also add .PHONY where appropriate, after all
these all are phony targets.
efi: rework OFFSETOF() based on __builtin_offsetof()
Since both LLVM and gcc supported this for a long time, we are not
adding a fallback compat kludge. And even if there's some relevant
compiler that doesn't know this concept, it'll fail with a compiler
error, and we'll fix it then.
Anita Zhang [Mon, 8 Oct 2018 03:28:36 +0000 (20:28 -0700)]
core: implement per unit journal rate limiting
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.
sulogin-shell: Use force if SYSTEMD_SULOGIN_FORCE set
When the root account is locked sulogin will either inform you of
this and not allow you in or if --force is used it will hand
you passwordless root (if using a recent enough version of util-linux).
Not being allowed a shell is ofcourse inconvenient, but at the same
time handing out passwordless root unconditionally is probably not
a good idea everywhere.
This patch thus allows to control which behaviour you want by
setting the SYSTEMD_SULOGIN_FORCE environment variable to true
or false to control the behaviour, eg. via adding this to
'systemctl edit rescue.service' (or emergency.service):
[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1
Distributions who used locked root accounts and want the passwordless
behaviour could thus simply drop in the override file in
/etc/systemd/system/rescue.service.d/override.conf
core: do not "warn" about mundane emergency actions
For example in a container we'd log:
Oct 17 17:01:10 rawhide systemd[1]: Started Power-Off.
Oct 17 17:01:10 rawhide systemd[1]: Forcibly powering off: unit succeeded
Oct 17 17:01:10 rawhide systemd[1]: Reached target Power-Off.
Oct 17 17:01:10 rawhide systemd[1]: Shutting down.
and on the console we'd write (in red)
[ !! ] Forcibly powering off: unit succeeded
This is not useful in any way, and the fact that we're calling an "emergency action"
is an internal implementation detail. Let's log about c-a-d and the watchdog actions
only.
units: allow and use SuccessAction=exit-force in system systemd-exit.service
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.
units: use SuccessAction=poweroff-force in systemd-poweroff.service
Explicit systemctl calls remain in systemd-halt.service and the system
systemd-exit.service. To convert systemd-halt, we'd need to add
SuccessAction=halt-force. Halting doesn't make much sense, so let's just
leave that is. systemd-exit.service will be converted in the next commit.
projects / thirdparty / systemd.git / log
