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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Some firmware supports sending input events for shift and logo keys.
Previously, we would suppress these with EFI_NOT_READY unless
some other key was pressed alongside, but it is really the job of the
caller to decide how to handle these.
Note that for keys that already have a printable shift representation
the reported input event will not have the shift key bits set
(Shift+a is reported as A). Should some firmware turn out to violate the
spec here we can always remove that part.
(cherry picked from commit 3f9973bf368475d1f2f7f587e7af728dd6d84e10)
In some cases there was a unlikely possibility that we would look
at an uninitialized key value.
Also, returning in case of unexpected input error cases should prevent
infinite looping.
(cherry picked from commit 1cb5d7857b205023a0473ec13df154ae2e254066)
It's not clear why we rescheduled a service auto restart while a stop job for
the unit was pending. The comment claims that the unit shouldn't be restarted
but the code did reschedule an auto restart meanwhile.
In practice that was rarely an issue because the service waited for the next
auto restart to be rescheduled, letting the queued stop job to be proceed and
service_stop() to be called preventing the next restart to complete.
However when RestartSec=0, the timer expired right away making PID1 to
reschedule the unit again, making the timer expired right away... and so
on. This busy loop prevented PID1 to handle any queued jobs (and hence giving
no chance to the start rate limiting to trigger), which made the busy loop last
forever.
This patch breaks this loop by skipping the reschedule of the unit auto restart
and hence not depending on the value of u->restart_usec anymore.
Fixes: #13667
(cherry picked from commit c972880640ee19e89ce9265d8eae1b3aae190332)
with addition of SD_ID128_MAKE_UUID_STR entries to src/shared/gpt.h the tool
failed halfway due to falsly matching the new entries
(cherry picked from commit 5fa87e9651074e8b78f632e43f0c2001a27f5b60)
The packages are installed to provide the dhcpd binary, used by
test/test-network/systemd-networkd-tests.py, but we don't need the units
to run, and in fact in some cases the image fails to boot because of
them:
Spawning container image on /home/runner/work/systemd/systemd/image.raw.
Press ^] three times within 1s to kill container.
● isc-dhcp-server.service loaded failed failed ISC DHCP IPv4 server
● isc-dhcp-server6.service loaded failed failed ISC DHCP IPv6 server
Container image failed with error code 1.
Error: Process completed with exit code 1.
Mask the units with an --extra-tree.
(cherry picked from commit 21838f36a64e71dd6439692e57d629f27e4954ea)
Currently the `--timestamp=` option has no effect on timestamps shown by
`systemctl show`, let's fix that.
Spotted in #22567.
Before:
```
$ systemctl show --timestamp=us+utc systemd-journald | grep Timestamp=
ExecMainStartTimestamp=Sat 2021-12-11 15:25:57 CET
StateChangeTimestamp=Sat 2021-12-11 15:25:57 CET
InactiveExitTimestamp=Sat 2021-12-11 15:25:57 CET
ActiveEnterTimestamp=Sat 2021-12-11 15:25:57 CET
ActiveExitTimestamp=Sat 2021-12-11 15:25:57 CET
InactiveEnterTimestamp=Sat 2021-12-11 15:25:57 CET
ConditionTimestamp=Sat 2021-12-11 15:25:57 CET
AssertTimestamp=Sat 2021-12-11 15:25:57 CET
```
After:
```
$ systemctl show --timestamp=us+utc systemd-journald | grep Timestamp=
ExecMainStartTimestamp=Sat 2021-12-11 14:25:57.177848 UTC
StateChangeTimestamp=Sat 2021-12-11 14:25:57.196714 UTC
InactiveExitTimestamp=Sat 2021-12-11 14:25:57.177871 UTC
ActiveEnterTimestamp=Sat 2021-12-11 14:25:57.196714 UTC
ActiveExitTimestamp=Sat 2021-12-11 14:25:57.144677 UTC
InactiveEnterTimestamp=Sat 2021-12-11 14:25:57.176331 UTC
ConditionTimestamp=Sat 2021-12-11 14:25:57.176980 UTC
AssertTimestamp=Sat 2021-12-11 14:25:57.176980 UTC
```
(cherry picked from commit a59e5c625da5a6e0c46e493d55f2f4212e9457ca)
There's currently a deadlock between PID 1 and dbus-daemon: in some
cases dbus-daemon will do NSS lookups (which are blocking) at the same
time PID 1 synchronously blocks on some call to dbus-daemon. Let's break
that by setting SYSTEMD_NSS_DYNAMIC_BYPASS=1 env var for dbus-daemon,
which will disable synchronously blocking varlink calls from nss-systemd
to PID 1.
In the long run we should fix this differently: remove all synchronous
calls to dbus-daemon from PID 1. This is not trivial however: so far we
had the rule that synchronous calls from PID 1 to the dbus broker are OK
as long as they only go to interfaces implemented by the broke itself
rather than services reachable through it. Given that the relationship
between PID 1 and dbus is kinda special anyway, this was considered
acceptable for the sake of simplicity, since we quite often need
metadata about bus peers from the broker, and the asynchronous logic
would substantially complicate even the simplest method handlers.
This mostly reworks the existing code that sets SYSTEMD_NSS_BYPASS_BUS=
(which is a similar hack to deal with deadlocks between nss-systemd and
dbus-daemon itself) to set SYSTEMD_NSS_DYNAMIC_BYPASS=1 instead. No code
was checking SYSTEMD_NSS_BYPASS_BUS= anymore anyway, and it used to
solve a similar problem, hence it's an obvious piece of code to rework
like this.
Issue originally tracked down by Lukas Märdian. This patch is inspired
and closely based on his patch:
https://github.com/systemd/systemd/pull/22038Fixes: #15316
Co-authored-by: Lukas Märdian <slyon@ubuntu.com>
(cherry picked from commit de90700f36f2126528f7ce92df0b5b5d5e277558)
It was removed back in 1684c56f40f020e685e70b3d1785d596ff16f892
Follow-up for: 1684c56f40f020e685e70b3d1785d596ff16f892
(cherry picked from commit cec16155e3dab4f123ba073223477a4ef2cf10f9)
A first step of removing blocking calls to the D-Bus broker from PID 1.
There's a lot more to got (i.e. grep src/core/ for sd_bus_creds
basically), but it's a start.
Removing blocking calls to D-Bus broker deals systematicallly with
deadlocks caused by dbus-daemon blocking on synchronous IPC calls back
to PID1 (e.g. Varlink calls through nss-systemd). Bugs such as #15316.
Also-see: https://github.com/systemd/systemd/pull/22038#issuecomment-1042958390
(cherry picked from commit e39eb045a502d599e6cd3fda7a46020dd438d018)
Previously we'd only watch configured service bus names if Type=dbus was
set. Let's also watch it for other types. This is useful to pick up the
main PID of such a service. In fact the code to pick it up was already
in place, alas it didn't do anything given the signal was never received
for it. Fix that.
(It's also useful for debugging)
(cherry picked from commit 1e8b312e5a22538f91defb89cf2997e09e106297)
These are filtered in `dns_scope_good_domain()`, but not synthesized.
Fixes#22229.
(cherry picked from commit 46b53e8035fb60c9a7f26dd32d6689ab3b7da97c)
Otherwise, if the second push is failed, then the first hashmap contains
dirty entry.
Also, this makes hashmap_remove_value() used when removing leases to
make not wrong lease is removed from the hashmap.
Note, this just hide the root cause of the issue #22253, which will be
fixed in later commit.
Fixes#22253.
(cherry picked from commit 8a7d048d1ddb8916482f1422405d3e0e4bccb279)
For some reason Ubuntu Focal repositories now have `llvm-13` virtual
package which can't be installed, but successfully fools our check,
resulting in no clang/llvm being installed...
```
$ apt show llvm-13
Package: llvm-13
State: not a real package (virtual)
N: Can't select candidate version from package llvm-13 as it has no candidate
N: Can't select versions from package 'llvm-13' as it is purely virtual
N: No packages found
$ apt install --dry-run llvm-13
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package llvm-13 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'llvm-13' has no installation candidate
```
(cherry picked from commit b491d74064f9d5e17a71b38b014434237169a077)
to limit the scope of the key to apt.llvm.org only.
This is mostly inspired by https://blog.cloudflare.com/dont-use-apt-key/
(cherry picked from commit bfa6bd1be098adc4710e1819b9cd34d65b3855da)
This effectively revert ab0c82d9f749cc397a6b7e0327ddb2c08cd7d7e0.
I have no idea why I did that...
Fixes#22559.
(cherry picked from commit 38488babe791639860068905177a415822b6b98b)
Fixes regression introduced in 599be274c13c503806c85073d7beb1a155ac27bd
Moving the Xen check before the CPUID check, in order to handle the case where
a Xen domain is nested within a hypervisor which can be detected by via the
CPUID check, had an unintended consequence of causing Dom0 to report as a Xen
VM when it is not nested.
This patch stops further checks once it has been determined that Dom0 is not
nested within another hypervisor, meaning that the non-nested case matches its
previous logic (where it does not report as a VM).
Also, tidy the conditionals for the Xen and UML checks by removing handling of
a VIRTUALIZATION_VM_OTHER result, which has no code path.
Fixes#22511
(cherry picked from commit ea583ed5a366cf51b80bd363db95e828a25ec27e)
This test fails on this branch:
949/1228 fuzz-dhcp-server-relay-message_clusterfuzz-testcase-minimized-fuzz-dhcp-server-relay-message-4972399731277824_address,undefined FAIL 0.00s (exit status 127)12:43
--- command ---12:43
01:47:36 UBSAN_OPTIONS='print_stacktrace=1:print_summary=1:halt_on_error=1' /usr/bin/env /tmp/autopkgtest-lxc.cl7c6fs0/downtmp/build.X6Z/src/build-deb/fuzz-dhcp-server-relay-message:address,undefined /tmp/autopkgtest-lxc.cl7c6fs0/downtmp/build.X6Z/src/test/fuzz/fuzz-dhcp-server-relay-message/clusterfuzz-testcase-minimized-fuzz-dhcp-server-relay-message-497239973127782412:43
--- stderr ---12:43
/usr/bin/env: ‘/tmp/autopkgtest-lxc.cl7c6fs0/downtmp/build.X6Z/src/build-deb/fuzz-dhcp-server-relay-message:address,undefined’: No such file or directory
This partially reverts commit 76bcd1d6d26ebe0424e2c5edc7f5a31a82ae3a7c.
The test fails on this branch:
948/1228 fuzz-dhcp-client_minimized-from-555a2b073b8d208655b68c294f8dfd592a11e50a_address,undefined FAIL 0.00s (exit status 127)12:43
--- command ---12:43
01:47:36 UBSAN_OPTIONS='print_stacktrace=1:print_summary=1:halt_on_error=1' /usr/bin/env /tmp/autopkgtest-lxc.cl7c6fs0/downtmp/build.X6Z/src/build-deb/fuzz-dhcp-client:address,undefined /tmp/autopkgtest-lxc.cl7c6fs0/downtmp/build.X6Z/src/test/fuzz/fuzz-dhcp-client/minimized-from-555a2b073b8d208655b68c294f8dfd592a11e50a12:43
--- stderr ---12:43
/usr/bin/env: ‘/tmp/autopkgtest-lxc.cl7c6fs0/downtmp/build.X6Z/src/build-deb/fuzz-dhcp-client:address,undefined’: No such file or directory
This reverts commit 87728a590ad82391e76a275024c9039625ff2b67.
ERROR:
Cannot use target systemd as a generator because it is built for the
host machine and no exe wrapper is defined or needs_exe_wrapper is
true. You might want to set `native: true` instead to build it for
the build machine.
(cherry picked from commit 0628d48ec2af1c25bede6d94ae49107b17651b68)
Conflicts:
meson.build
If we're going upwards in the journal file during entry iteration and we
can't reach the current entry due to corruption, start iterating upwards
from the last reachable entry array. This is equivalent to skipping
all entries in the array that can't be reached anymore.
Fixes#22431
(cherry picked from commit 952d1e784a0ad47e0c2c832d28299987c3c25529)
8d801e35cb155faa08235a5af8b4d6ad60715837 didn't take into account
upwards iteration of entry items when we're working on a corrupted
journal file. Instead of moving to the previous entry array, we'd
always move to the next array, regardless of the iteration direction.
To fix this, we introduce bump_entry_array() that moves to the next
or previous entry array depending on the given direction. Since the
entry array chains are singly linked lists, we have to start iterating
from the front to find the previous array. We only reach this logic
if we're working on a corrupted journal file so being slow here shouldn't
matter too much.
(cherry picked from commit aa00163d79309f9873512a4cc14a48c05fee7c65)
If the query get CNAME or DNAME, then the query will be restarted.
Even in that case, previously, the event source was freed and allocated
again. Let's slightly optimize it.
(cherry picked from commit ecdfb9a1ae0a09d22a976e2ca0dc99aacc6b9d1f)
Fortunately, unlike the issue fixed in the previous commit, the memleak
should be superficial and not become apparent, as the queries handled
here are managed by the stub stream, and will be freed when the stream
is closed.
Just for safety, and slightly reducing the runtime memory usage by the
stub stream.
(cherry picked from commit fe8c5ce615ee2123f17b1f0b3728c439e19e4b5b)
