This adds a timeout if the TTY cannot be acquired and makes sure we
always output the question to the console, never to the TTY of the
respective service.
This makes sure that
systemctl status /home
is implicitly translated to:
systemctl status /home.mount
Similar, /dev/foobar becomes dev-foobar.device.
Also, all characters that cannot be part of a unit name are implicitly
escaped.
Supposed to prevent creating unit files like:
├── dev-sda1.device.wants
│ └── .dot.mount -> /run/systemd/generator/.dot.mount
├── .dot.mount
from:
# cat /etc/fstab
/dev/sda1 /.dot vfat ro 1 3
which we later skip reading because of the leading '.'.
This reverts commit 9b5af248f0.
Udev now explicitely labels only files/directories in /dev. The selinux
array API is not released and will not work on other distros at this moment.
src/shared/util.c includes <sys/capability.h> but doesn't use anything
defined there. Since <sys/capability.h> is part of libcap, not libc,
don't require it.
Allows systemd-without-udevd to require fewer external libraries.
systemd-udev is currently incorrectly labeling /run/udev/* content because it is
using selinux prefix labeling of /dev. This patch will allow systemd-udev to
use prefix labeling of /dev and /run.
This takes handling of chassis power and sleep keys as well as the lid
switch over from acpid.
This logic is enabled by default for power and sleep keys, but not for
the lid switch.
If a graphical session is in the foreground no action is taken under the
assumption that the graphical session does this.
This also ensures that caps dropped from the bounding set are also
dropped from the inheritable set, to be extra-secure. Usually that should
change very little though as the inheritable set is empty for all our uses
anyway.
Previously generated units were always placed at the end of the search
path. With this change there will be three unit dirs instead of one, to
place generated entries at the beginning, in the middle and at the end
of the search path:
beginning: for units that need to override all configuration, regardless
of user or vendor. Example use: system-update-generator uses this to
temporarily redirect default.target.
middle: for units that need to override vendor configuration, but not
vendor configuration. Example use: /etc/fstab should override vendor
supplied configuration (think /tmp), but should not override native user
configuration.
end: does not override anything but is available as well. Possible usage
might be to convert D-Bus bus service files to native units but allowing
vendor supplied native units to win.
Checking the device major/minor is not a good idea. Let's replace this
with an explicit flag file, which we model after /etc/os-release and
call /etc/initrd-release.
This should help making the boot process a bit easier to explore and
understand for the administrator. The simple idea is that "systemctl
status" now shows a link to documentation alongside the other status and
decriptionary information of a service.
This patch adds the necessary fields to all our shipped units if we have
proper documentation for them.
The alignment of the "[ OK ]" and "[FAILED]" status marks to the right
side of the terminal makes it difficult to link them with the messages
on the left if your console is wide.
I considered the options:
1. Align them to the 80th column regardless of the console width.
Disadvantage - either:
- truncating messages needlessly, not using available space; or
- If the message is long, write the mark over it. => ugly
2. Write them to the 80th column for short messages,
and further to the right for longer ones.
Disadvantage:
- jagged look
3. Write the marks on the left, before the message.
Disadvantage:
- Breaks tradition from RHL.
Advantages:
+ slightly simpler code
+ Will annoy holy-traditionalists.
I chose option 3.
BTW, Debian now uses similar marks on the left with its makefile-style
boot.
Special values of the "status" argument to status_vprintf are:
NULL - no status mark, no message indentation
"" - no status mark, message indented as if the mark was there
The red "[ABORT]" for a dependency failure is too scary.
It suggests a crash. And it suggests a problem with the unit itself.
Change it to a yellow "[DEPEND]" message. The color communicates the
level of seriousness better.
