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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I picked the list of zone files to install by grepping through the code. This
is is a bit brittle, but installing all of them takes a while, and more
importantly, writes a lot of lines to the log.
The kernel does not sanitize /proc/cmdline. E.g. when running under qemu, it is
easy to pass a string with newline by mistake. We use read_one_line_file(), so
we would read only the first list of the file, and
write_string_file(WRITE_STRING_FILE_VERIFY_ON_FAILURE) would fail because the
target file is obviously different. Change to a kernel-generated file to avoid
the issue.
v2:
- use /proc/version instead of /proc/uptime for attempted writes, so the test
test passes even if test_write_string_file_verify() takes more than 10 ms ;]
Sometimes the test would fail there, nondeterministically. I'm not sure why,
but relying on PID1 not caching the file is clearly very brittle. Let's instead
call daemon-reload.
Unfortunately meson does not install symlinks, but copies the symlink
destination instead. So symlinks need to be created by a script.
This commit adds both symlinks in test/testsuite-08.units/ and meson
scriptlet calls. Strictly speaking, the first is not necessary, since nothing
reads stuff directly from the source tree.
I put SELINUX=disabled on my laptop, and the test fails with ENOENT when trying
to write to /sys/fs/selinux/enforce. It's a bit of a special case, but let's
avoid the failure.
The test currently fails in the check for LimitNOFILESoft/LimitNOFILE. I see
default values there. This doesn't seem to be related to the changes in the
test suite, but rather to the recent changes to pid1.
journal_file_fstat() returns an error if we call it on already unlinked
journal file and hence we never reach remove_file_real() which is the
entire point.
I must have made some mistake while testing the fix that got me thinking
the issue is gone while opposite was true.
Fixes#14695
This is work in progress and not finished yet. However, I hope to have
captured some of the key points that came up in previous discussions
with appropriate notes about things that still need to be defined.
I may revisit it later. Also, feel free to completely rewrite if the
format is not quite right.
