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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
a931ad47a8 added the explicit Delegate=yes|no
switch, but it was initially set to 'yes'.
acc8059129 disabled delegation for user@.service
with the justication that CPU accounting is expensive, but half a year later
a88c5b8ac4 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: 8d9156660d
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 846f1da465.
The commit 846f1da465 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.
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.
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.
