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.)
sd-netlink: allow sd_netlink_message_read() to be used for union types
Before, sd_netlink_message_read() expected to fill a buffer completely,
and would return -EIO if the attribute being read was shorter than the
buffer. This means that the function can be used to "peek" into attributes
(by specifying a short buffer to just read part of the attribute), but
cannot be used to read something into a union without knowing beforehand
which specific field in the union is being filled. That latter operation
seems more useful (messages are short, so we don't really need to do partial
reads), so let's allow reads that don't fill the output buffer completely.
In places the text was overly formal, e.g. "an 128-bit ID" was repeated, even
though it is clear from the context that we're talking about this type of ID.
OTOH, in other places the text was informal, e.g. "You can use …".
Also, "you may use f() to frob" → "f() frobs". The text without all the
flourishes is easier to read.
sd_id128_in_set_sentinel() was described only in passing when taking about
sd_id128_in_set(), now it gets is own brief paragraph.
sd-id128: rename and export sd_id128_string_equal()
We find this function useful in our code, so no reason not to export it.
I changed the order of last two words in the name to match the arguments.
(With "equal_string" I expected sd_id128_t first, string second, but in
actual use, the second argument is usually a long constant so it's nice
to keep this order of arguments.)
The usual: if we find that function useful, other users of the library
will too. In particular, the v-variants are necessary to build pass-thru
wrappers.
It had two symbols which were not actually exported because they were not
listed in libsystemd.sym. They were also entirely unused in our codebase.
I don't think it makes much sense to export just those two functions, and
it doesn't make to build a string processing library in systemd either.
History of the file shows that it was created in faaa5728d956b7f0d24f27f3341d0b9fff30af00 'utf8: export utf8 validation functions as part of sd-bus'
and hasn't gone even one non-trivial change since then ;)
It was added originally in 65f568bbeb9b8c70200e44c19a797df3a0bfd485. The API is
has stabilized pretty much, and generally follows the usual style for
libsystemd. We've held it as a public-but-private library for almost 10 years,
let's export it.
sd_netlink_sendv() and sd_nfnl_nft_*() are excluded.
Before we had the following scheme:
mempool_enabled() would check mempool_use_allowed, and
libsystemd-shared would be linked with a .c file that provides mempool_use_allowed=true,
while other things would linked with a different .c file with mempool_use_allowed=false.
In the new scheme, mempool_enabled() itself is a weak symbol. If it's
not found, we assume false. So it only needs to be provided for libsystemd-shared,
where it can return false or true.
test-set-disable-mempool is libshared, so it gets the symbol. But then we
actually disable the mempool via envvar. mempool_enable() is called to check
its return value directly.
sd-id128: avoid an unnecessary function call in inline helper
When optimizing, the compiler will most likely replace the call to memcmp(),
but at -O0, the code that is emitted builds the call preamble and does the
call. Let's use the same pattern as with sd_id128_is_null() and
sd_id128_is_allf() and avoid the call.
The function `data_object_in_hash_table()` calls
`journal_file_move_to_object()` with `OBJECT_DATA`. Hence,
previously obtained pointer to a data object may be now invalid.
projects / thirdparty / systemd.git / log
