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 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.
So far we had various ad hoc APIs to query search paths:
systemd-analyze unit-paths, lookup_paths_log(), the pkgconfig file,
debug logs emitted by systemd-analyze cat-config.
But answering a simple question "what is the search path for tmpfiles,
sysusers, .network files, ..." is surprisingly hard.
I think we should have an api that makes it easy to query this. Pkgconfig is
not bad, but it is primarily a development tool, so it's not available in many
context. Also it can't provide support for paths which are influenced by
environment variables, and I'd like to be able to answer the question "what is
the search path for ..., assuming that VAR_FOO=... is set?".
Extending sd-path to support more of our internal paths seems to be most
flexible solution. We already have systemd-path which provides a nice
way to query, and we can add stuff like optional descriptions later on.
We we essentially get a nice programmatic and commmandline apis for the price
of one.
The two functions were duplicating a lot of functionality and more
importantly, they both had explicit lists of types which are search
paths. I want to add more types, and I don't want to have to remember
to add them to both lists.
