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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We ask for the TTL, then have enough space for it.
We probably can drop the extra cmsg space now, but let's figure that out
another time, since the extra cmsg space is used elsewhere in resolved
as well.
if someone implements https://systemd.io/BLOCK_DEVICE_LOCKING/ then we
shouldn't loudly complain about that.
This reverts back to the original behaviour from
3ebdb81ef088afd3b4c72b516beb5610f8c93a0d: when the lock is taken we
silently skip processing the device and sending out the messages for it.
This is a fix-up for a7c71d214c37797d82de2f66cfe0a0a79c3a5c92: since we
now don't wait for the job to finish anymore right after enqueuing it,
we should not exit our ptyfwd logic before the unit is back to inactive
*and* no job pending anymore.
Suppose a service has WatchdogSec set to 2 seconds in its unit file. I
then start the service and WatchdogUSec is set correctly:
% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=2s
Now I call `sd_notify(0, "WATCHDOG_USEC=10000000")`. The new timer seems
to have taken effect, since I only send `WATCHDOG=1` every 4 seconds,
and systemd isn't triggering the watchdog handler. However, `systemctl
show` still shows WatchdogUSec as 2s:
% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=2s
This seems surprising, since this "original" watchdog timer isn't the
one taking effect any more. This patch makes it so that we instead
display the new watchdog timer after sd_notify(WATCHDOG_USEC):
% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=10s
Fixes#15726.
sd-boot uses rdtsc to set those timestamps. There is no guarantee that the tsc
has any particular absolute value.
On my VM:
$ head /sys/firmware/efi/efivars/LoaderTime*
==> /sys/firmware/efi/efivars/LoaderTimeExecUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f <==
4397904074
==> /sys/firmware/efi/efivars/LoaderTimeInitUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f <==
4396386839
==> /sys/firmware/efi/efivars/LoaderTimeMenuUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f <==
4396392521
$ build/test-boot-timestamps
...
LoaderTimeExecUSec=4396386839 too large, refusing.
Failed to read EFI loader data: Input/output error
Assertion 'q >= 0' failed at src/test/test-boot-timestamps.c:84, function main(). Aborting.
(with patch)
$ build/test-boot-timestamps
...
EFI Loader: start=1h 13min 16.386s exit=1h 13min 17.904s duration=1.517s
Firmware began 1h 13min 17.904074s before kernel.
Loader began 1.517235s before kernel.
Firmware began Tue 2020-05-26 11:04:13 CEST.
Loader began Tue 2020-05-26 12:17:30 CEST.
Kernel began Tue 2020-05-26 12:17:31 CEST.
This generator can be used by desktop environments to launch autostart
applications and services. The feature is an opt-in, triggered by
xdg-desktop-autostart.target being activated.
Also included is the new binary xdg-autostart-condition. This binary is
used as an ExecCondition to test the OnlyShowIn and NotShowIn XDG
desktop file keys. These need to be evaluated against the
XDG_CURRENT_DESKTOP environment variable which may not be known at
generation time.
Co-authored-by: Henri Chain <henri.chain@enioka.com>
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.
Only log at LOG_INFO level, i.e. make this informational. During start
let's leave it at LOG_WARNING though.
Of course, it's ugly leaving processes around like that either in start
or in stop, but at start its more dangerous than on stop, so be tougher
there.
In our regular gettys the actual shell commands live the the session
scope anyway (as long as logind is used). Hence, let's avoid
KillMode=process, it serves no purpose and is simply unsafe since it
disables systemd's own process lifecycle management.
