Reduce the number of iterations in some of the test cases, since they
generate a huge amount of uevents and basically DoS udev (which can't
keep up while being slowed down by ASan). To avoid this, let's reduce
the number of iterations and bump the timeout when running under ASan,
since we're not interested in performance in such cases.
test: avoid overriding an already existing EXIT handler
TEST-70 specified its own EXIT handler, which replaced the
`cleanup_loopdev` handler, so the loop device was always hanging around
once this test was run. Let's use the new `add_at_exit_handler()` stuff
to mitigate this.
Bash allows only one handler per signal, so let's overcome this
limitation by having one dedicated EXIT signal which runs all registered
handlers from all over the place.
- use test_append_files() to install additional commands
- drop use of expect
- include assert.sh and use assertions at several places
- use timeout command at several places
- always use logind-test-user
- etc
Michal Sekletar [Fri, 27 May 2022 19:11:37 +0000 (21:11 +0200)]
logind: don't start user@UID.service instance for background sessions
We have had background session class for a long time (since commit e2acb67baa), but so far the only difference in handling of background
sessions was logging, i.e. we log some messages with LOG_DEBUG for such
sessions.
Previously there were complains [1] about excessive logging for each
time cron session is started. We used to advise user to enable lingering
for users if they want to avoid these log messages. However, on servers
with a lot of users the extra processes that result from lingering just
adds too much overhead. Hence I think that our current handling of
background sessions is not ideal and we should make better use of this
attribute.
This commit introduces a change in default behavior of logind. Logind is
now not going to start user instance of systemd when background session
is created and that should address excessive logging problem for cron
where background class is used by default. When the same user actually
logs in normally then user instance will be started as previously.
Also note that PAM_TTY variable is now always set to some value for PAM
sessions started via PAMName= option. Otherwise we would categorize such
sessions as "background" and user manager won't be started.
I think is very simple, but flexible. The date may be set early, for distros
that have a fixed schedule, but it doesn't have to. So for example Debian could
push out an update that sets a few months before the release goes EOL. And
various tools, in particular graphical desktops, can start nagging people to
upgrade a few weeks before the date.
As discussed in the bug, we don't need granularity higher than a day. And this
means that we can use a simple human- and machine-readable format.
I was considering other names, e.g. something with "EOL", but I think that
"SUPPORT_END" is better because it doesn't imply that the machine will somehow
stop working. This is supposed to be an advisory, nothing more.
Thomas Haller [Wed, 6 Jul 2022 12:50:50 +0000 (14:50 +0200)]
fundamental: adjust #if conditional for _fallthrough_ for clang
NetworkManager takes systemd sources. It gets compiler warnings
related to _fallthrough_. They probably can also affect systemd
itself.
A) on RHEL-7, gcc 4.8.5-44.el7 we get:
../src/libnm-systemd-shared/src/fundamental/macro-fundamental.h:45:22: error: "__clang__" is not defined [-Werror=undef]
#if __GNUC__ >= 7 || __clang__
^
Presumably gcc older than 7 is supported, so fix this.
B) on Ubuntu 18.04, clang 1:6.0-41~exp5~ubuntu1 we get:
../src/libnm-systemd-core/src/libsystemd-network/sd-dhcp6-client.c:746:17: error: declaration does not declare anything [-Werror,-Wmissing-declarations]
_fallthrough_;
^
../src/libnm-systemd-shared/src/fundamental/macro-fundamental.h:46:25: note: expanded from macro '_fallthrough_'
# define _fallthrough_ __attribute__((__fallthrough__))
^
Granted, README comments that clang >= 10 is required. However,
parts of systemd build just fine with older clang. It seems unnecessary
to break this and the fix helps NetworkManager.
Fixes: c0f5d58c9ab7 ('meson: Document why -Wimplicit-fallthrough is not used with clang')
json: actually use numeric C locale we just allocated
This fixes formatting of JSON real values, and uses C locale for them.
It's kinda interesting that this wasn't noticed before: the C locale
object we allocated was not used, hence doing the dance had zero effect.
This makes "test-varlink" pass again on systems with non-C locale.
(My guess: noone noticed this because "long double" was used before by
the JSON code and that had no locale supporting printer or so?)
user: delegate cpu controller, assign weights to user slices
So far we didn't enable the cpu controller because of overhead of the
accounting. If I'm reading things correctly, delegation was enabled for a while
for the units with user and pam context set, i.e. for user@.service too. a931ad47a8623163a29d898224d8a8c1177ffdaf added the explicit Delegate=yes|no
switch, but it was initially set to 'yes'. acc8059129b38d60c1b923670863137f8ec8f91a disabled delegation for user@.service
with the justication that CPU accounting is expensive, but half a year later a88c5b8ac4df713d9831d0073a07fac82e884fb3 changed DefaultCPUAccounting=yes for
kernels >=4.15 with the justification that CPU accounting is inexpensive there.
In my (very noncomprehensive) testing, I don't see a measurable overhead if the
cpu controller is enabled for user slices. I tried some repeated compilations,
and there is was no statistical difference, but the noise level was fairly
high. Maybe better benchmarking would reveal a difference.
The goal of this change is very simple: currently all of the user session,
including services like the display server and pipewire are under user@.service.
This means that when e.g. a compilation job is started in the session's
app.slice, the processes in session.slice compete for CPU and can be starved.
In particular, audio starts to stutter, etc. With CPU controller enabled,
I can start start 'ninja -C build -j40' in a tab and this doesn't have any
noticable effect on audio.
I don't think the particular values matter too much: the CPU controller is
work-convserving, and presumably the session slice would never need more than
e.g. one 1 full CPU, i.e. half or a quarter of available CPU resources on even
the smallest of today's machines. app.slice and session.slice are assigned
equal weights, background.slice is assigned a smaller fraction. CPUWeight=100
is the default, but I wrote it explicitly to make it easier for users to see
how the split is done. So effectively this should result in session.slice
getting as much power as it needs.
If if turns out that this does have a noticable overhead, we could make it
opt-in. But I think that the benefit to usability is important enough to enable
it by default. W/o something like this the session is not really usable with
background tasks.
tree-wide: add global ascii_isdigit() + ascii_isalpha()
We now have a local implementation in string-util-fundamental.c, but
it's useful at a lot of other places, hence let's give it a more
expressive name and share it across the tree.
The "Networking" section has a lonely single document listed right now,
even though the "Concepts" section has two more network related docs.
Move them over, let's end this loneliness.
tree-wide: link to docs.kernel.org for kernel documentation
https://www.kernel.org/ links to https://docs.kernel.org/ for the documentation.
See https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=ebc1c372850f249dd143c6d942e66c88ec610520
When we start, the contents of the variable match the name. But then
in the loop, the variable doesn't point at the old head any more. So let's
rename it to something with a plural.
This was a trivial wrapper that didn't provide any added value. With more
complicated structures like strvs, hashmaps, sets, and arrays, it is possible
to have an empty container. But in case of a list, the list is empty only when
the head is missing.
Also, we generally want the positive condition, so we replace many
if (!LIST_IS_EMPTY(x)) with just if (x).
gcc was warning that found_fs_uuid was used unitialized. The issue stemmed from
the call to open(), where gcc seemingly didn't know that errno must be negative.
When that is set, we can drop some unnecessary initializations without warnings.
The commit 846f1da465beda990c1c01346311393f485df467 made systemd.unit=
filtered out from the command line. That causes debug-generator does not
work as expected on daemon-reexecute, and we cannot call `systemctl
daemon-reexecute` in our test suite running on nspawn.
Fixes issue reported in https://github.com/systemd/systemd/pull/23851#issuecomment-1170992052.
In function 'sd_id128_equal',
inlined from 'journal_file_verify' at ../src/libsystemd/sd-journal/journal-verify.c:1047:29:
../src/systemd/sd-id128.h:119:43: error: 'entry_boot_id.qwords[0]' may be used uninitialized [-Werror=maybe-uninitialized]
119 | return a.qwords[0] == b.qwords[0] && a.qwords[1] == b.qwords[1];
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/libsystemd/sd-journal/journal-verify.c: In function 'journal_file_verify':
../src/libsystemd/sd-journal/journal-verify.c:823:20: note: 'entry_boot_id.qwords[0]' was declared here
823 | sd_id128_t entry_boot_id;
| ^~~~~~~~~~~~~
cc1: all warnings being treated as errors
entry_boot_id is only used when entry_monotonic_set has been set, and that's
only done in one place where entry_boot_id is also initalized.
units: add IgnoreOnIsolate=yes to systemd-journald too
We already had it on the socket units, so it's possible that
systemd-journald.service would be stopped and then restarted when trafic hits
the sockets when something logs. Let's not try to stop it. It is supposed to
run until the end and be eventually killed in the final killing spree.
Currently kde installs a fake utmp session to listen for this. This provides an
alternative mechanism as discussed in #23574.
Example with 'shutdown 6 -r' and shutdown -c':
PRIORITY=6
SYSLOG_FACILITY=4
SYSLOG_IDENTIFIER=systemd-logind
...
CODE_FILE=src/login/logind-utmp.c
CODE_LINE=90
CODE_FUNC=warn_wall
MESSAGE_ID=9e7066279dc8403da79ce4b1a69064b2
OPERATOR=root
MESSAGE=The system will reboot at Thu 2022-06-30 12:16:43 CEST!
ACTION=reboot
PRIORITY=5
SYSLOG_FACILITY=4
SYSLOG_IDENTIFIER=systemd-logind
...
OPERATOR=root
CODE_FILE=src/login/logind-dbus.c
CODE_LINE=2407
CODE_FUNC=method_cancel_scheduled_shutdown
MESSAGE=System shutdown has been cancelled
MESSAGE_ID=249f6fb9e6e2428c96f3f0875681ffa3
ACTION=reboot
We have RxBufferSize= and TxBufferSize= in .link files. Let's use the same
abbreviation here. OTOH, "inc" could be short for "increment" or "increase",
let's avoid that.
sd-event: let sd_event_source_set_enabled accept NULL
Same story as before: disabling a non-existent event source shouldn't
need to be guarded by an if. I retained the wrapper so that that we don't
have to say SD_EVENT_OFF in the many places where this is called.
sd-event: allow sd_event_source_is_enabled() to return false for NULL
This is a natural use case, and instead of defining a wrapper to do this
for us, let's just make this part of the API. Calling with NULL was not
allowed, so this is not a breaking change to the interface.
(After sd_event_source_is_enabled was originally added, we introduced
sd_event_source_disable_unref() and other similar functions which accept
NULL. So not accepting NULL here is likely to confuse people. Let's just
make the API usable with minimal fuss.)
projects / thirdparty / systemd.git / log
