RUN seems to be used primarily for historical reasons over the more
immediate IMPORT command. As a side-effect, RUN also runs *after* all the
rules have been processed which is not really what we want here - we expect
the device to be updated immediately. Other rules that rely on accurate evdev
axes should be able to assume the axes are already present. So let's use
IMPORT here.
For consistency, the second two rules are split across multiple lines as well.
systemd.show-status=error is useful for the case where people care about errors
only.
If people want to have a quiet boot, they most likely don't want to see all
status output even if there is a delay in boot, so make "quiet" imply
systemd.show-status=error instead of systemd.show-status=auto.
Fixes#14976.
We would flip to status=temporary mode on the first error, and then switch back
to status=auto after the initial transaction was done. This isn't very useful,
because usually all the messages about successfully started units and not
related to the original failure. In fact, all those messages most likely cause
the information about the prime error to scroll off screen. And if the user
requested quiet boot, there's no reason to think that they care about those
success messages.
Also, when logging about dependency cycles, treat this similarly to a unit
error and show the message even if the status is "soft disabled" (before we
wouldn't show it in that case).
When we are booting with show-status=on, normally new status updates happen a
few times per second. Thus, it is reasonable to start showing the cylon eye
after 5 s, because that means a significant delay has happened. When we are
running with show-status=off or show-status=auto (and no error had occured),
the user is expecting maybe 15 to 90 seconds with no output (because that's
usually how long the whole boot takes). So we shouldn't bother the user with
information about a few seconds of delay. Let's make the timeout 25s if we are
not showing any messages.
Conversly, when we are outputting status messages, we can show the cylon eye
with a shorter delay, now that we removed the connection to enablement status.
Let's make this 2s, so users get feedback about delays more quickly.
We know if we created the file before, no need to repeat the operation. The
state in /run should always match our internal state. Since we call
manager_set_show_status() quite often internally, this saves quite a few
pointless syscalls.
We would say "Enabling" also for SHOW_STATUS_AUTO, which is actually
"soft off". So just print the exact state to make things easier to understand.
Also add a helper function to avoid repeating the enum value list.
For #14814.
Unlike newer Medion Akoya E* models for which we have a generic
wildcard match, this model uses a somewhat older KIOX0009 accelerometer.
Not only does our generic catch all not match, we also need a different
matrix for this model, so add a model-specific entry for it.
In a user namespace container:
Feb 28 12:45:53 0b2420135953 systemd[1]: Starting Home Manager...
Feb 28 12:45:53 0b2420135953 systemd[21]: systemd-homed.service: Failed to set up network namespacing: Operation not permitted
Feb 28 12:45:53 0b2420135953 systemd[21]: systemd-homed.service: Failed at step NETWORK spawning /usr/lib/systemd/systemd-homed: Operation not permitted
Feb 28 12:45:53 0b2420135953 systemd[1]: systemd-homed.service: Main process exited, code=exited, status=225/NETWORK
Feb 28 12:45:53 0b2420135953 systemd[1]: systemd-homed.service: Failed with result 'exit-code'.
Feb 28 12:45:53 0b2420135953 systemd[1]: Failed to start Home Manager.
We should treat this similarly to the case where network namespace are not
supported at all.
https://bugzilla.redhat.com/show_bug.cgi?id=1807465
The man pages state that the '+' prefix in Exec* directives should
ignore filesystem namespacing options such as PrivateTmp. Now it does.
This is very similar to #8842, just with PrivateTmp instead of
PrivateDevices.
Without changing the SELinux label for private /dev of a service, it will take
a generic file system label:
system_u:object_r:tmpfs_t:s0
After this change it is the same as without `PrivateDevices=yes`:
system_u:object_r:device_t:s0
This helps writing SELinux policies, as the same rules for `/dev` will apply
despite any `PrivateDevices=yes` setting.
Where we have a device that looks like a mouse and is connected over i2c, tag
it as pointing stick. There is no such thing as a i2c mouse.
Even touchpads that aren't recognized by the kernel will not show up as i2c
mouse - either the touchpad follows the Win8.1 specs in which case the kernel
switches it to multitouch mode and it shows up like a touchpad. The built-in
trackpoint, if any, is then the i2c mouse device.
Where the touchpad doesn't follow the spec, the kernel will not handle it and
the touchpad remains on the PS/2 legacy bus - not i2c. Hence we can assume
that any i2c mouse device is really a pointing stick.
the modalias reported by udev is acpi:BOSC0200:BOSC0200: but the rules
only matched acpi:BOSC0200:BOSC0200 (without the trailing colon)
change to acpi:BOSC0200* as in other models
This prevents an error in pam_systemd when logging in.
sshd[2623165]: pam_unix(sshd:session): session opened for user tony.stark(uid=10001) by (uid=0)
sshd[2623165]: pam_systemd(sshd:session): Failed to get user record: Invalid argument
Bug: https://bugs.gentoo.org/708824
Currently, if deactivation of the primary swap unit fails:
# LANG=C systemctl --no-pager stop dev-mapper-fedora\\x2dswap.swap
Job for dev-mapper-fedora\x2dswap.swap failed.
See "systemctl status "dev-mapper-fedora\\x2dswap.swap"" and "journalctl -xe" for details.
then there are still the running stop jobs for all the secondary swap units
that follow the primary one:
# systemctl list-jobs
JOB UNIT TYPE STATE
3233 dev-disk-by\x2duuid-2dc8b9b1\x2da0a5\x2d44d8\x2d89c4\x2d6cdd26cd5ce0.swap stop running
3232 dev-dm\x2d1.swap stop running
3231 dev-disk-by\x2did-dm\x2duuid\x2dLVM\x2dyuXWpCCIurGzz2nkGCVnUFSi7GH6E3ZcQjkKLnF0Fil0RJmhoLN8fcOnDybWCMTj.swap stop running
3230 dev-disk-by\x2did-dm\x2dname\x2dfedora\x2dswap.swap stop running
3234 dev-fedora-swap.swap stop running
5 jobs listed.
This remains endlessly because their JobTimeoutUSec is infinity:
# LANG=C systemctl show -p JobTimeoutUSec dev-fedora-swap.swap
JobTimeoutUSec=infinity
If this issue happens during system shutdown, the system shutdown appears to
get hang and the system will be forcibly shutdown or rebooted 30 minutes later
by the following configuration:
# grep -E "^JobTimeout" /usr/lib/systemd/system/reboot.target
JobTimeoutSec=30min
JobTimeoutAction=reboot-force
The scenario in the real world seems that there is some service unit with
KillMode=none, processes whose memory is being swapped out are not killed
during stop operation in the service unit and then swapoff command fails.
On the other hand, it works well in successful case of swapoff command because
the secondary jobs monitor /proc/swaps file and can detect deletion of the
corresponding swap file.
This commit fixes the issue by finishing the secondary swap units' jobs if
deactivation of the primary swap unit fails.
Fixes: #11577
Zbigniew Jędrzejewski-Szmek
Peter Hutterer
Yu Watanabe
Daniele Medri
Hans de Goede
Topi Miettinen
Nate Jones
Topi Miettinen
Anita Zhang
Rocka
Balint Reczey
Lukas K
Mike Gilbert
James Buren
HATAYAMA Daisuke