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 only matters for the case where new networkctl is running against older
networkd. We should still handle the old error to avoid unnecessary warning
about speedmeeter being disabled.
This partially reverts commit e813de549b.
Don't try to show top level drop-in for non-existent units or when trying to
instantiate non-instantiated units:
$ systemctl cat nonexistent@.service
Assertion 'name' failed at src/shared/dropin.c:143, function unit_file_find_dirs(). Aborting.
$ systemctl cat systemd-journald@.service
Assertion 'name' failed at src/shared/dropin.c:143, function unit_file_find_dirs(). Aborting.
Otherwise, systemd-udev-trigger|settle.service that ran in the initrd may
ramain active, and never re-run again from the system root.
This is observed by forexample examining ESP with udevadm info, which in the
initrd has all the ID_* variables, and none of them in fully booted system.
The code existed in machinectl to use stdin/stdout if the path for
import/export tar/raw was empty or dash (-) but a check to
`fd_verify_regular` in importd prevented it from working.
Update the check instead to explicitly check for regular file or
pipe/fifo.
Fixes#14346
The variable is always initialized, but the compiler might not notice
that. With gcc-9.2.1-1.fc31:
$ CFLAGS='-Werror=maybe-uninitialized -Og' meson build
$ ninja -C build
[...]
../src/basic/tmpfile-util.c: In function ‘mkostemp_safe’:
../src/basic/tmpfile-util.c:76:12: error: ‘fd’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
76 | if (fd < 0)
| ^
Ideally, we would want to report this over back over dbus. But that is pretty hard,
because the unitfile parsing logic doesn't provide any feedback.
systemd-analyze verify also doesn't notice the issue, because it doesn't look
at the [Install] section at all. Let's print a message in the logs at least.
