IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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?)
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.
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.
Follow-up for: 8d9156660d6958c8d63b1d44692968f1b5d33920
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.
On Ubuntu, cryptsetup does not link against libgcc_s.so.1 which leads to
the following test failure in TEST-70-TPM2:
systemd[1]: Starting testsuite-70.service...
systemd[329]: testsuite-70.service: Executing: /usr/lib/systemd/tests/testdata/units/testsuite-70.sh
testsuite-70.sh[329]: + export SYSTEMD_LOG_LEVEL=debug
testsuite-70.sh[329]: + SYSTEMD_LOG_LEVEL=debug
testsuite-70.sh[329]: + img=/var/tmp/test.img
testsuite-70.sh[329]: + dd if=/dev/zero of=/var/tmp/test.img bs=1024k count=20 status=none
testsuite-70.sh[329]: + echo -n passphrase
testsuite-70.sh[329]: + cryptsetup luksFormat -q --use-urandom /var/tmp/test.img /tmp/passphrase
testsuite-70.sh[333]: libgcc_s.so.1 must be installed for pthread_exit to work
testsuite-70.sh[329]: /usr/lib/systemd/tests/testdata/units/testsuite-70.sh:
line 12: 333 Aborted (core dumped) cryptsetup luksFormat -q --use-urandom $img /tmp/passphrase
To fix this, manually install libgcc_s.so.1 to the test image if running
on Debian-like systems.
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.
Fixes a bug introduced by 846f1da465beda990c1c01346311393f485df467.
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.
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.
This might (or not) help with #23287.
