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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The openssl binary is an optional dependency.
If systemd has been built with OpenSSL support, we want to test its
OpenSSL functionality.
So record a failure message in /failed if the binary is missing.
See https://github.com/systemd/systemd/pull/21724#issuecomment-992707614
link_address_is_dynamic() is costful in general. Call it only when
KeepConfiguration= is set.
Note, it is not necessary to check link->network in the loop, as we have
the assertion for that in the beginning of the function.
If KERNEL_INSTALL_MACHINE_ID is defined in /etc/machine-info, prefer it
over the machine ID from /etc/machine-id. If a machine ID is defined in
neither /etc/machine-info nor in /etc/machine-id, generate a new UUID
and try to write it to /etc/machine-info as KERNEL_INSTALL_MACHINE_ID
and use it as the machine ID if writing it to /etc/machine-info succeeds.
In practice, this means we have a more robust fallback if there's no
machine ID in /etc/machine-id than just using "Default" and allows
image builders to force kernel-install to use KERNEL_INSTALL_MACHINE_ID
by simply writing it to /etc/machine-info themselves.
Otherwise we might miss the "Device path too long" message:
```
[ 21.083274] testsuite-64.sh[374]: swapoff /dev/vda1
[ 21.089841] testsuite-64.sh[376]: ++ mktemp
[ 21.095115] testsuite-64.sh[271]: + logfile=/tmp/tmp.a1MULA35wL
[ 21.095115] testsuite-64.sh[271]: + journalctl -b -q --no-pager -o short-monotonic -p info --grep 'Device path.*vda.?'\'' too long to fit into unit name'
...
[ 21.277360] systemd[1]: testsuite-64.service: Main process exited, code=exited, status=1/FAILURE
[ 21.277508] systemd[1]: testsuite-64.service: Failed with result 'exit-code'.
...
[ 21.323500] systemd[1]: Device path '/sys/devices/pci0000:00/0000:00:03.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/0000:04:00.0/0000:05:00.0/0000:06:00.0/0000:07:00.0/0000:08:00.0/0000:09:00.0/0000:0a:00.0/0000:0b:00.0/0000:0c:00.0/0000:0d:00.0/0000:0e:00.0/0000:0f:00.0/0000:10:00.0/0000:11:00.0/0000:12:00.0/0000:13:00.0/0000:14:00.0/0000:15:00.0/0000:16:00.0/0000:17:00.0/0000:18:00.0/0000:19:00.0/0000:1a:00.0/virtio0/block/vda/vda1' too long to fit into unit name, ignoring device.
```
The way that the cryptsetup plugins were built was unnecessarilly complicated.
We would build three static libraries that would then be linked into dynamic
libraries. No need to do this.
While at it, let's use a convenience library to avoid compiling the shared code
more than once.
We want the output .so files to be located in the main build directory,
like with all consumable build artifacts, so we need to maintain the split
between src/cryptsetup/cryptsetup-token/meson.build and the main meson.build
file.
AFAICT, the build artifacts are the same: exported and undefined symbols are
identical. There is a tiny difference in size, but I think it might be caused
by a different build directory name.
It doesn't make much sense to do this, the result is very similar to including
to objects directly in the output binary without going through an intermediate
target.
The linkage of test-libudev was rather strange too: udev_link_with is used to
allow udev to be linked to a static version of libshared, so that udev is not
linked to libshared.so. But here we were using both, defeating the purpose of
udev_link_with. I don't think it matters what the test is linked to, so let's
use the non-static linkage to save space.
The meson default for static_library() are:
build_by_default=true, install=false. We never interact with the
static libraries, and we only care about them as a stepping-stone towards
the installable executables or libraries. Thus let's only build them if
they are a dependency of something else we are building.
While at it, let's drop install:false, since this appears to be the default.
This change would have fixed the issue with lib_import_common failing
to build too: we wouldn't attempt to build it.
In practice this changes very little, because we generally only declare static
libraries where there's something in the default target that will make use of
them. But it seems to be a better pattern to set build_by_default to false.
Use a 'convenience library' to do the compilation once and then link the
objects into all the files that need it. Those files are small, so this probably
doesn't matter too much for speed, but has the advantage that we don't get the
same error four times if something goes wrong.
The library is conditionalized in the same way importd itself, because we
cannot build it without the deps.
The ordering of the service wrt. to udevd is enforced by unit configuration,
so no need to tell the user about this. From users' POV, the only thing that
counts is that the unit is enabled and then the right thing happens.
It is used by udevd and networkd. Since udevd is enabled statically, let's also
change the preset to "on". networkd is opt-in, so let's pull in the generator
when enabling networkd too.
Let's not try to be overly clever here. This code path is not overly
performance sensitive and we should avoid trying to outsmart the kernel
without proper benchmarking.
pread() is not guaranteed to completely fill up the given buffer with
data which we assumed until now. Instead, only increment the offset by
the number of bytes that were actually read.
The variable is not useful outside of the loop (it'll always be null
after the loop is finished), so we can declare it inline in the loop.
This saves one variable declaration and reduces the chances that somebody
tries to use the variable outside of the loop.
For consistency, 'de' is used everywhere for the var name.
This was an undocumented change in behavior introduced by
9e82a74cb0. Previously, we only
checked for "Default" if we didn't find a machine ID. Let's make
sure we keep the previous behavior intact.
We get "upstream" dns server config from ~three places: /etc/resolv.conf,
config files, and runtime config via dbus. With this commit, we'll filter out
our own stub listeners if they are configured in either of the first two
sources. For /etc/resolv.conf this is done quitely, and for our own config
files, a LOG_INFO message is emitted, since this is a small inconsistency in
the config.
Setting loops like this over dbus is still allowed. The reason is that in the
past we didn't treat this as an error, and if we were to start responding with
an error, we could break a scenario that worked previously. E.g. NM sends us a
list of servers, and one happens to be the our own. We would just not use that
stub server before, but it'd still be shown in the dbus properties and such.
We would have to return error for the whole message, also rejecting the other
valid servers. I think it's easier to just keep that part unchanged.
Test case:
$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 57 Dec 15 10:26 /etc/resolv.conf
$ cat /etc/resolv.conf
nameserver 192.168.150.1
options edns0 trust-ad
search .
$ cat /etc/systemd/resolved.conf.d/stub.conf
[Resolve]
DNSStubListenerExtra=192.168.150.1
$ resolvectl
...
Global
resolv.conf mode: foreign
DNS Servers: 192.168.150.1
Fallback DNS Servers: ...
(with the patch):
Global
resolv.conf mode: foreign
Fallback DNS Servers: ...
The message that the "journal begins … ends …" has been always confusing to
users. (Before b91ae210e6 it was "logs begin … end …" which was arguably even
more confusing, but really the change in b91ae210e6 didn't substantially change
this.)
When the range shown is limited (by -e, -f, --since, or other options), it
doesn't really matter to the user what the oldest entries are, since they are
purposefully limiting the range. In fact, if we are showing the last few
entries with -e or -f, knowing that many months the oldest entries have is
completely useless.
And when such options are *not* used, the first entry generally corresponds to
the beginning of the range shown, and the last entry corresponds to the end of
that range. So again, it's not particularly useful, except when debugging
journalctl or such. Let's just treat it as a debug message.
Fixes#21491.
The idea is to be able to distinguish whether we're in a VM/container or something
more substantial at a glance.
Chassis: laptop 💻
Chassis: tablet 具
Chassis: vm 🖴
Chassis: server 🖳
Chassis: handset 🕻
Chassis: watch ⌚
Chassis: desktop 🖥
Chassis: container ☐
