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 test is failing becuase the setup state isn't reaching 'configured'
for unknown reasons; ignore the setup state for now to prevent failures
of CI until the reason can be investigated.
Prompted by systemd/systemd#16111.
* check if /var is a mountpoint - if not, something went wrong. In case
of systemd/systemd#16111 the /failed file was created, because
systemd-cryptsetup failed, but it ended up being empty, making the result
check incorrectly pass
* forward journal messages to console - if we fail to mount /var,
journald won't flush logs to the persistent storage and we end up
empty handed and with no clue what went wrong
For example, without systemd/systemd#16111 and with this patch:
...
[FAILED] Failed to start systemd-cryptsetup@varcrypt.service.
See 'systemctl status systemd-cryptsetup@varcrypt.service' for details.
[DEPEND] Dependency failed for cryptsetup.target.
...
[ 3.882451] systemd-cryptsetup[581]: Key file /etc/varkey is world-readable. This is not a good idea!
[ 3.883946] systemd-cryptsetup[581]: WARNING: Locking directory /run/cryptsetup is missing!
[ 3.884846] systemd-cryptsetup[581]: Failed to load Bitlocker superblock on device /dev/disk/by-uuid/180ba5ef-873b-4018-9968-47c23431f71a: Invalid argument
...
[ 4.099451] sh[606]: + mountpoint /var
[ 4.100025] sh[603]: + systemctl poweroff --no-block
[ 4.101636] systemd[1]: Finished systemd-user-sessions.service.
[ 4.102598] sh[608]: /var is not a mountpoint
[FAILED] Failed to start testsuite-02.service.
dm-verity support in dissect-image at the moment is restricted to GPT
volumes.
If the image a single-filesystem type without a partition table (eg: squashfs)
and a roothash/verity file are passed, set the verity flag and mark as
read-only.
After today's Arch Linux image update, there seems to be a slight change
in delay reporting which breaks some asserts in
systemd-networkd-tests.py:
Expected:
limit 100 delay 50.0ms 10.0ms loss 20%
Current:
limit 100 delay 50ms 10ms loss 20%
Note that run_test() calls coredumpctl in a loop because in certain
environments (1 vCPU unaccelerated QEMU VM) it might take quite a
while to process the coredump.
This test runs fine locally (both on Qemu and nspawn) but sporadically fails on
autopkgtest for some reason.
Disable it while the issue is investigated to reduce noise.
The time-based cache allows starting a new unit without an expensive
daemon-reload, unless there was already a reference to it because of
a dependency or ordering from another unit.
If the cache is out of date, check again if we can load the
fragment.
In DHCPv6-PD environment, where WAN interface requests IPv6 via DHCPv6,
receives the address as well as delegated prefixes, with LAN interfaces
serving those delegated prefixes in their router advertisement messages.
The LAN interfaces on the router themselves do not have
the IPv6 addresses assigned by networkd from the prefix it
serves on that interface. Now this patch enables it.
Let's create new images public by default and then symlink/copy them
into the respective private directories afterwards, not the other way
around. This should fix a nasty race condition in parallel runs where
one tests attempts to copy the backing public image at the same moment
another test is already modifying it.
The test currently doesn't actually test configure-without-carrier since
it does have carrier for the entire test. It now forces carrier down
before starting the network portion of the test. Also, it tests to verify
the configuration is retained across future carrier losses/gains.
This allows users to configure a subnet id that should be used instead
of automatically (sequentially) assigned subnets. The previous attempt
had the downside that the subnet id would not be the same between
networkd restarts. In some setups it is desirable to have predictable
subnet ids across restarts of services and systems.
The code for the assignment had to be broken up into two pieces. One of
them is the old (sequential) assignment of prefixes and the other is the
new assignment based on configured subnet ids. The new assignment code
has to be executed first and has to be taken into account when (later
on) allocating the "old" subnets from the same pool.
Instead of having one iteration through the links we are now trying to
allocate a prefix for every link on every delegated prefix, unless they
received an assignment in a previous iteration.
Defines how link-local and autoconf addresses are generated.
0: generate address based on EUI64 (default)
1: do no generate a link-local address, use EUI64 for addresses generated
from autoconf
2: generate stable privacy addresses, using the secret from
stable_secret (RFC7217)
3: generate stable privacy addresses, using a random secret if unset
In the linked reproducer, m->fields_size == 0, and we calculate ri == -1, which
of course doesn't end well. Skip the whole calculation if m->fields_size == 0,
and also check that we don't go negative even if it is non-zero.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19446 and #15583.
Support running tests in parallel by switching to copying of the
base image instead of symlinking it..
This still requires some setup steps, like running `make setup` on tests
which have unique $IMAGE_NAME beforehand (and sequentially), otherwise
they'll all try to create the same base image when started in parallel,
leading to nasty issues. However, as running the integration tests in
parallel is such an unusual use case it should be good enough, for now.
Fixes: oss-fuzz#22208
```
test/fuzz/fuzz-calendarspec/oss-fuzz-22208... ../src/shared/calendarspec.c:666:48: runtime error: signed integer overflow: 2147000000 + 1000000 cannot be represented in type 'int'
#0 0x7f0b9f6cc56a in prepend_component ../src/shared/calendarspec.c:666
#1 0x7f0b9f6cd03a in parse_chain ../src/shared/calendarspec.c:718
#2 0x7f0b9f6cea1c in parse_calendar_time ../src/shared/calendarspec.c:845
#3 0x7f0b9f6d1397 in calendar_spec_from_string ../src/shared/calendarspec.c:1084
#4 0x401570 in LLVMFuzzerTestOneInput ../src/fuzz/fuzz-calendarspec.c:17
#5 0x401ae0 in main ../src/fuzz/fuzz-main.c:39
#6 0x7f0b9e31b1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
#7 0x40122d in _start (/home/fsumsal/repos/systemd/build/fuzz-calendarspec+0x40122d)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/shared/calendarspec.c:666:48 in
```
Link groups are similar to port ranges found in managed switches.
You can add network interfaces to a numbered group and perform operations
on all the interfaces from that group at once.
Check:
- There is only 3 messages logged with type stdout
- Check all messages logged does not have new line: LINE_BREAK=eof
- Check that the 3 messages are logged from a different PID
- Check the 3 MESSAGE= content
As documented in systemd.path(5):
When a service unit triggered by a path unit terminates (regardless
whether it exited successfully or failed), monitored paths are
checked immediately again, and the service accordingly restarted
instantly.
This commit implements this behaviour for PathExists=, PathExistsGlob=,
and DirectoryNotEmpty=. These predicates are essentially
"level-triggered": the service should be activated whenever the
predicate is true. PathChanged= and PathModified=, on the other hand,
are "edge-triggered": the service should only be activated when the
predicate *becomes* true.
The behaviour has been broken since at least as far back as commit
8fca6944c2 ("path: stop watching path specs once we triggered the target
unit"). This commit had systemd stop monitoring inotify whenever the
triggered unit was activated. Unfortunately this meant it never updated
the ->inotify_triggered flag, so it never rechecked the path specs when
the triggered unit deactivated.
With this commit, systemd rechecks all paths specs whenever the
triggered unit deactivates. If any PathExists=, PathExistsGlob= or
DirectoryNotEmpty= predicate passes, the triggered unit is reactivated.
If the target unit is activated by something outside of the path unit,
the path unit immediately transitions to a running state. This ensures
the path unit stops monitoring inotify in this situation.
With this change in place, commit d7cf8c24d4 ("core/path: fix spurious
triggering of PathExists= on restart/reload") is no longer necessary.
The path unit (and its triggered unit) is now always active whenever
the PathExists= predicate passes, so there is no spurious restart when
systemd is reloaded or restarted.
Systems where a mount point is expected to be read-write needs a way to
fail mount units that fallback as read-only.
Add a property to allow setting the -w option when calling mount(8).
As Debian/Ubuntu use /lib/systemd instead of /usr/lib/systemd,
add systemd-journal-remote to the list of programs that test-functions
detects the correct path to, and replace its direct usage with
$SYSTEMD_JOURNAL_REMOTE
Also use $JOURNALCTL instead of journalctl.
Also minor correction in install_plymouth() to look in /lib/... as
well as /usr/lib/... and /etc/...
Remove the artifact files indicating test result (testok, failed, and
skipped) just before running the test so we always get the latest and
most relevant result instead of incorrectly consuming previous results.
Discovered in https://github.com/systemd/systemd/pull/15378#issuecomment-616801873
The disk attributes can take some time to update on certain filesystems,
so let's strip them from inputs of both `homectl` and `userdbctl` before
comparing them to avoid unexpected fails.
Also, switch from `cmp` to `diff` to make a potential test fail a bit more
debuggable.
Fixes: #14755
Let's append the date to the domain in the file name, to be able
to have multiple versions for the same domain.
There is no particular rhyme or reason to the domains being used:
I just pulled a few domains that happened to be present in issues reported
on github, even though the issues were not about pretty printing.
This doesn't really matter, since in non-/usr-merged systems plymouth
needs to be in /bin and on merged ones it doesn't matter, but it is
still prettier to insert the right path, and avoid /bin on merged
systems, since it's just a compat symlink.
Replaces: #15351
Give systemd a chance to process the stop event before checking if the
PID has indeed leaked. This should fix the intermittent test fails in CI
even with a fixed systemd version, like this one:
```
Apr 08 10:22:09 testsuite-47.sh[345]: ++ cat /leakedtestpid
Apr 08 10:22:09 testsuite-47.sh[334]: + leaked_pid=342
Apr 08 10:22:09 testsuite-47.sh[334]: + systemctl stop testsuite-47-repro
Apr 08 10:22:10 testsuite-47.sh[334]: + ps -p 342
Apr 08 10:22:10 testsuite-47.sh[348]: PID TTY TIME CMD
Apr 08 10:22:10 testsuite-47.sh[348]: 342 ? 00:00:00 sleep
Apr 08 10:22:10 testsuite-47.sh[334]: + exit 42
```
Followup to 197298ff9f
