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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Clean up the naming of the sd-path enums. Previously, the more recently
added fields where named in the form SD_PATH_xyz_DIR and
SD_PATH_xyz_PATH, while the older fields where called just SD_PATH_xyz
and SD_PATH_SEARCH_xyz. Let's clean this up, to come to a more unified
way how we name this stuff.
I opted to stick to the old naming, i.e. dropthe suffixes. It's a bit of
a bike-shedding question of course, but I think there's a good reason to
avoid the additional DIR and PATH suffixes: the enum prefix contains
"PATH" anyway (i.e. "SD_PATH_"), so including PATH twice in each name is
redundant. Moreover, the key difference between the enums with the "dir"
and the "path" in the name is that the latter are *seach* paths, and I
think this is better emphasized by sticking to the "SEARCH" in the name.
Moreover dropping the suffixes makes the identifiers a lot shorter, in
particular in the "systemd-path" list output. And that's always good.
This means the naming pkgconfig file and in sd-path slightly deviate
(though the mapping is very simple), but I think that's OK, given that
this is developer facing and not user facing.
ROOTPREFIX doesn't include the trailing /, hence add it in where needed.
Also, given that sysctl.d/, binfmt.d/, sysusers.d/ are generally
accessed before /var/ is up they should use ROOTPREFIX rather than
PREFIX. Fix that.
After a larger transaction, e.g. after bootup, we're left with an empty hashmap
with hundreds of buckets. Long-term, it'd be better to size hashmaps down when
they are less than 1/4 full, but even if we implement that, jobs hashmap is
likely to be empty almost always, so it seems useful to deallocate it once the
jobs count reaches 0.
Possibly fixes#15220. (There might be another leak. I'm still investigating.)
The leak would occur when the path cache was rebuilt. So in normal circumstances
it wouldn't be too bad, since usually the path cache is not rebuilt too often. But
the case in #15220, where new unit files are created in a loop and started, the leak
occurs once for each unit file:
$ for i in {1..300}; do cp ~/.config/systemd/user/test0001.service ~/.config/systemd/user/test$(printf %04d $i).service; systemctl --user start test$(printf %04d $i).service;done
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>
