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.
core: limit service-watchdogs=no to actual "watchdog" commands
The setting is now only looked at when considering an action for a job timeout
or unit start limit. It is ignored for ctrl-alt-del, SuccessAction, SuccessFailure.
v2: turn the parameter into a flag field
v3: rename Options to Flags
core: accept system mode emergency action specifiers with a warning
Before we would only accept those "system" values, so there wasn't other
chocie. Let's provide backwards compatiblity in case somebody made use of
this functionality in user mode.
v2: use 'exit-force' not 'exit'
v3: use error value in log_syntax
core: define "exit" and "exit-force" actions for user units and only accept that
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
man: move description of *Action= modes to FailureAction=/SuccessAction=
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.
core: consider service with no start command immediately started
The service would always be in state == SERVICE_INACTIVE, but it needs to go
through state == SERVICE_START so that SuccessAction/FailureAction are executed.
main: bump fs.nr_open + fs.max-file to their largest possible values
After discussions with kernel folks, a system with memcg really
shouldn't need extra hard limits on file descriptors anymore, as they
are properly accounted for by memcg anyway. Hence, let's bump these
values to their maximums.
This also adds a build time option to turn thiss off, to cover those
users who do not want to use memcg.
projects / thirdparty / systemd.git / log
