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 the following spurious logs on enumerating links:
```
wlan0: Saved original MTU 1500 (min: 256, max: 2304)
wlan0: MTU is changed: 0 → 1500 (min: 256, max: 2304)
```
Previously (v248 or earlier), even if no static address is configured,
the link did not enter configured state, as e.g. Link::static_addresses_configured
is false until the link gained its carrier.
But, after the commit 1187fc3375, the
situation was changed. Static addresses, routes, and etc are requested even
if the link does not have its carrier, and thus the link enters configured
state when no static address and etc are specified.
This makes the link does not enter configured state before it gains its
carrier when at least one of dynamic address assignment protocols (e.g.
DHCP) except for NDISC is enabled.
Note that, unfortunately, netplan always enables ConfigureWithoutCarrier=
for all virtual devices, e.g. bridge. See,
978e20f902
So, we need to support e.g. the following strange config:
```
[Netowkr]
ConfigureWithoutCarrier=yes
DHCP=yes
```
Fixes#19855.
Say that r should be declared at the top of the function.
Don't say that fixed buffers result in truncation, right after saying that they
must only be used if size is known.
Adjust order of examples to be consistent.
Cgroups may be unnecessarily realized when they are not needed. This
happens, e.g. for mount units parsed from /proc/$PID/mountinfo, check
touch /run/ns_mount
unshare -n sh -c "mount --bind /proc/self/ns/net /run/ns_mount"
# no cgroup exists
file /sys/fs/cgroup/system.slice/run-ns_mount.mount
systemctl daemon-reload
# the vain cgroup exists
file /sys/fs/cgroup/system.slice/run-ns_mount.mount
. (Such cgroups can account to a large number with many similar mounts.)
The code already accounts for "lazy" realization (see various checks for
Unit.cgroup_realized) but the unit_deserialize() in the reload/reexec
path performs unconditional realization.
Invalidate (and queue) the units for realization only if we know that
they were already realized in the past. This is a safe thing to do even
in the case the reload brings some new cgroup setting (controllers, BPF)
because units that aren't realized will use the updated setting when the
time for their realization comes. (It's not even needed to add a code
comment because the current formulation suggests the changed behavior.)
I wanted to see what is_path_read_only_fs() and is_path_temporary_fs() return
in a chroot, and various tests would fail. For most of our codebase, we can
assume that /proc and such are mounted, and it doesn't make sense to make the
tests work in a chroot. But let's do it here. (In general, it would be useful
for most stuff in src/basic/, since it's linked into libraries which might be
invoked in incorrectly set up environments and should not fail too badly.)
a70581ffb5 added ExecRuntime.ipcns_storage_socket[], and
serialization in exec_runtime_serialize(), and deserialization in exec_runtime_deserialize_one(),
but also deserialization in exec_runtime_deserialize_compat(). exec_runtime_deserialize_compat()
is for deserializating ExecRuntime when it was serialized as part of the unit before
e8a565cb66. There was never any code which would serialize
ExecRuntime.ipcns_storage_socket[] this way, so the deserialization attempts are pointless.
All unit types can be serialized. This function was really checking whether the
unit type has custom serialization/deserialization code. But we don't need a
function for this.
Also, the check that both .serialize() and .deserialize_item() are defined is
better written as an assert. Not we have a function which would skip
serialization/deserializaton for the unit if we forgot to set either of the
fields.
Apparently people use such large key files. Specifically, people used 4M
key files, and we lowered the limit from 4M to 4M-1 back in 248.
This raises the limit to 64M for read_full_file() to avoid these
specific issues and give some non-trivial room beyond the 4M files seen
IRL.
Note that that a 64M allocation in glibc is always immediately done via
mmap(), and is thus a lot slower than shorter allocations. This means
read_virtual_file() becomes ridiculously slow if we'd use the large
limit, since we use it all the time for reading /proc and /sys metadata,
and read_virtual_file() typically allocates the full size with malloc()
in advance. In fact it becomes so slow, that test-process-util kept
timing out on me all the time, once I blindly raised the limit.
This patch hence introduces two distinct limits for read_full_file() and
read_virtual_file(): the former is much larger than the latter and the
latter remains where it is. This is safe since the former uses an
exponentially growing realloc() loop while the latter uses the
aforementioend ahead-of-time full limit allocation.
Fixes: #19193
When we have a unit which cannot be enabled:
# foo@.service:
...
[Install]
WantedBy=foo.target # there is no instance, so we don't know what to enable
we should throw an error when invoked directly with 'enable', but
not when doing 'preset' or 'preset-all'.
Fixes#19856.
