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 upcoming kernel enumerates Logitech 27 MHz wireless keyboards and
mice by there wireless-PID, rather then using the PID of the receiver
which is the same for all 27MHz Logitech devices.
This allows us to add per model keymappings for the special keys on these
keyboards. This commit adds such mappings for the "Logitech Rechargeable
Desktop" keyboard (modelnumber Y-RK49).
The upcoming kernel enumerates Logitech 27 MHz wireless keyboards and
mice by there wireless-PID, rather then using the PID of the receiver
which is the same for all 27MHz Logitech devices.
This allows us to add per model keymappings for the special keys on these
keyboards. This commit adds such mappings for the "Logitech Cordless
Access Keyboard" (modelnumber Y-RH35).
The upcoming kernel enumerates Logitech 27 MHz wireless keyboards and
mice by there wireless-PID, rather then using the PID of the receiver
which is the same for all 27MHz Logitech devices.
This will allow us to add per model keymappings for the special keys on
these keyboards, which may differ per model.
This commit adds a default / fallback mapping, assigning the most common
meaning of the custom Logitech c10XX keycodes.
The link may not have corresponding .network file.
Note that in that case, link_ipv4ll_enabled() and link_dhcp4_enabled()
returns false. So, it is safe to drop the assertion.
Fixes#12422.
When booting with "udev.log-priority=debug" for example, the output might be
spammed with messages like this:
systemd-udevd[23545]: maximum number (248) of children reached
systemd-udevd[23545]: maximum number (248) of children reached
systemd-udevd[23545]: maximum number (248) of children reached
systemd-udevd[23545]: maximum number (248) of children reached
systemd-udevd[23545]: maximum number (248) of children reached
systemd-udevd[23545]: maximum number (248) of children reached
systemd-udevd[23545]: maximum number (248) of children reached
While the message itself is useful, printing it per batch of events should be
enough.
By default, the available completions are sorted alphabetically, which
is counterproductive in case of syslog priorities. Override the default
behavior using the `nosort` option
When systemd is started, it detects initrd by checking for that file
The usage of that file is not documented anywhere, so mention it early
in the most relevant man-page I could find.
When we determine that a calendar expression cannot elapse anymore,
print a warning but proceed regardless like we normally would.
Quite possibly a remote system has a different understanding of time
(timezone, system clock) than we have, hence we really shouldn't change
behaviour here client side, but log at best, and then leave the decision
what to do to the server side.
Follow-up for #12299
Coverity doesn't like the fact that unit_get_cgroup_context() returns NULL for
unit types that don't have a CGroupContext. We don't expect to call those
functions with such unit types, so this isn't an immediate problem, but we can
make things more robust by handling this case.
CID #1400683, #1400684.
- bridge or bonding master takes a reference of slave links.
- drop link from bridge or bonding master's slave list when slave link
is removed.
- change type of Link::slaves to Set*,
Fixes#12315.
When a uevent is received during the relevant interface is in
LINK_STATE_PENDING, then the interface may be initialized twice.
To prevent that, this introduces LINK_STATE_INITIALIZED.
https://github.com/systemd/systemd/issues/7153#issuecomment-485252308
Apparently this is still confusing for people.
Longer-term, I think we should just make BindMount= automatically "upgrade"
(or "downgrade", depending on how you look at this), any InaccessiblePath=
mountpoints to "tmpfs". I don't see much point in forcing users to remember
this interaction. But let's at least document the status quo, we can always
update the docs if the code changes.
A service might be able to detect errors by itself that may require the
system to take the same action as if the service locked up. Add a
WATCHDOG=trigger state change notification to sd_notify() to let the
service manager know about the self-detected misery and instantly
trigger the configured watchdog behaviour.
The interface provided by those two functions is huge, so this text could
probably be made two or three times as long if all details were described.
But I think it's a good start.
