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.
File names in /etc, /run, /usr/lib are sorted/overridden by basename.
Sorting things like "/dev/null" with the basename "null" in the hash
of config files breaks the ordering and the overriding logic.
This macro comes from kernel and it's useful for unwrapping structs
inside another one. The generated code is actually the same to the one
where this logic is used in udev, but using this macro is much cleaner
and less error prone.
In some cases the main/control PID of a service can be outside of the
services cgroups (for example, if logind readjusts the processes'
cgroup). In order to clarify this for the user show the main/control PID
in the cgroup tree nonetheless, but mark them specially.
Lennart Poettering
Harald Hoyer
Frederic Crozat
Michal Schmidt
Andreas Schwab
Kay Sievers
Lucas De Marchi
Sven Anders