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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As with other units, stopping of the automount requires actual work,
and without the ordering dependency systemd might not execute the stop
job before shutdown.target is reached and units ordered after that are
executed.
I have a system with /usr/lib/repart.d/50-root.conf with GrowFileSystem=yes.
The partition wouldn't be resized in the initrd, because
ConditionDirectoryNotEmpty=|/sysusr/usr/lib/repart.d was evaluated very early,
before /sysroot was mounted. There was no ordering dependency between
systemd-repart.service and sysroot.mount. (There was After=initrd-usr-fs.target,
but it seems to be only referred to by systemd-fstab-generator, which in my
case doesn't even run, because there's no fstab.)
But in fact, we neeed to run systemd-repart in the initrd only in limited
circumstances: when we need to create the root device based on config under
sysusr.mount. If there is config on the root device, it can be executed in
the host system, early during boot. Thus, let's remove the condition on
/sysroot/…. Without an ordering dependency on sysroot.mount, it was subject to
a race condition anyway. (A race condition with a low probability of "winning",
because systemd-repart.service has no dependencies, but sysroot.mount requires
a device to be detected and the mount to happen.)
The other problem was that systemd-repart.service didn't have the ordering wrt.
initrd-switch-root.target, so it was subject to the same race condition that
was fixed for other units in 7c0e2b555968d70ac563a37e32a6931ee90961a6. (If the
systemd-repart.service/stop job is slow, we could end up not restarting
systemd-repart.service in the host system.)
With the changes here, I see systemd-repart.service/start running twice:
in the initrd it is skipped because the conditions fail, and then in the
host system it runs normally.
Note: support for /sysroot is retained in systemd-repart code. I don't see a
strong reason to remove it, since it may still be useful to people invoking
repart in the initrd in other circumstances.
No functional change, just a cleanup to make the subsequent changes easier to
see. This is a continuation of 9810e419425263bde86787bc21251f1ad3c35628
> The block is reordered and split to have:
> 1. description + documentation
> 2. (optionally) conditions
> 3. all the dependencies
The dependencies for shutdown.target are listed separately because they are the
other deps are for startup, and shutdown.target only matter much later.
Re-watching pids on cgroup v1 (needed because of unreliability of cgroup
empty notifications in containers) is handled bellow at the end of
service_sigchld_event() and depends on value main_pid_known flag.
In CentOS Stream 8 container on cgroup v1 the stop action would get stuck
indefinitely on unit like this,
$ cat /run/systemd/system/foo.service
[Service]
ExecStart=/bin/bash -c 'trap "nohup sleep 1 & exit 0" TERM; sleep infinity'
ExecStop=/bin/bash -c 'kill -s TERM $MAINPID'
TimeoutSec=0
However, upstream works "fine" because in upstream version of systemd we
actually never wait on processes killed in containers and proceed
immediately to sending SIGKILL hence re-watching of pids in the cgroup
is not necessary. But for the sake of correctness we should merge the
patch also upstream.
We ship with empty /var, so /var/log/journal does not exist, which
means journald does not do persistent logging. Let's fix that by
setting the config to explicitly enable persistent logging.
Since bash has no namespaces, let's do the second best thing and prefix
all "internal" stuff with an underscore, to minimize the chance of a name
conflict in the future.
This reverts commit 1db6dbb1dcdacfd7d2b4c84562fc6e77bc8c43a5.
The original patch was reverted because of issue #25369. The issue was created
because it wrongly assumed that sd_journal_seek_tail() seeks to 'current' tail.
But in fact, only when a subsequent sd_journal_previous() is called that it's
pointing to the tail at that time. The concept of 'tail' in sd_journal_seek_tail()
only has a logical meaning, and a sd_journal_previous is needed. In fact, if we
look at the codes in journalctl, we can see sd_journal_seek_tail() is followed by
sd_journal_previous(). By contrary, a sd_journal_next() after a 'logical' tail does
not make much sense. So the original patch is correct, and projects that are
using 'sd_journal_next()' right after 'sd_journal_seek_tail()' should do fixes
as in https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2823#note_1637715.
This illustrates bug in sd_journal_next() or friends;
calling sd_jounral_next() followed by sd_journal_seek_tail() makes the
location saved in sd-journal something corrupted, and subsequent
sd_journal_previous() or friends may fail or provides unexpected result.
When udevadm verify is invoked by an analyzer tool like rpminspect
to verify individual udev rules files, the summary just clutters the
output, so provide an option to turn the summary off.
This adds two verbs, edit and cat, to networkctl for
operating on network configs (namely .network, .netdev
and .link files). Specially, if the config name is
prefixed by @, it will be treated as network interface
name, and operations will be performed on config files
associated with the link.
Closes#26906
As it might hide a possible allocation error since it uses
the returns_nonnull attribute:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==8==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000004 (pc 0x7f317897db8d bp 0x7ffd436fe9a0 sp 0x7ffd436fe970 T0)
==8==The signal is caused by a WRITE memory access.
==8==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
#0 0x7f317897db8d in source_new /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:1214:18
#1 0x7f317897e68c in sd_event_add_time /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:1417:13
#2 0x7f317897a0f6 in event_reset_time /work/build/../../src/systemd/src/libsystemd/sd-event/event-util.c:68:21
#3 0x4e2c8e in client_initialize_time_events /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1366:13
#4 0x4eb0fd in client_initialize_events /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1380:9
#5 0x4eb0fd in client_start_delayed /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1410:16
#6 0x4e30aa in client_start /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1415:16
#7 0x4e30aa in sd_dhcp_client_start /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:2045:13
#8 0x4e700e in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/libsystemd-network/fuzz-dhcp-client.c:73:15
#9 0x5062f8 in NaloFuzzerTestOneInput (/build/fuzz-dhcp-client+0x5062f8)
#10 0x525283 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#11 0x524a6a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#12 0x526139 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#13 0x526e05 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#14 0x51616f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#15 0x516a38 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
#16 0x506555 in main (/build/fuzz-dhcp-client+0x506555)
#17 0x7f3177ce3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#18 0x420c4d in _start (/build/fuzz-dhcp-client+0x420c4d)
Found by Nallocfuzz.
In case one of the allocations fails.
For example:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==17==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fb352a476e5 bp 0x7ffe45154850 sp 0x7ffe45154008 T0)
==17==The signal is caused by a READ memory access.
==17==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
#0 0x7fb352a476e5 (/lib/x86_64-linux-gnu/libc.so.6+0x1886e5) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#1 0x435878 in __interceptor_strlen /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc
#2 0x4de1e4 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-calendarspec.c:20:21
#3 0x4deea8 in NaloFuzzerTestOneInput (/build/fuzz-calendarspec+0x4deea8)
#4 0x4fde33 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#5 0x4fd61a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#6 0x4fece9 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#7 0x4ff9b5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#8 0x4eed1f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#9 0x4ef5e8 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
#10 0x4df105 in main (/build/fuzz-calendarspec+0x4df105)
#11 0x7fb3528e3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#12 0x41f80d in _start (/build/fuzz-calendarspec+0x41f80d)
Found by Nallocfuzz.
