Much like logind has a client in loginctl, and journald in journalctl
introduce timedatectl, to change the system time (incl. RTC), timezones
and related settings.
Turns out cpuset needs explicit initialization before we could make use
of it. Thus mounting cpuset with cpu/cpuacct would make it impossible to
just create a group in "cpu" and start it.
Instead of doing hand optimized fd bisect arrays just use plain old
hashmaps. Now I can understand my own code again. Yay!
As a side effect this should fix some bad memory accesses caused by
accesses after mmap(), introduced in 189.
Note: I did s/MANAGER/SYSTEMD/ everywhere, even though it makes the
patch quite verbose. Nevertheless, keeping MANAGER prefix in some
places, and SYSTEMD prefix in others would just lead to confusion down
the road. Better to rip off the band-aid now.
When the new PID is invoked the journal socket from the initrd might
still be around. Due to the default log target being journal we'd log to
that initially when the new main systemd initializes even if the kernel
command line included a directive to redirect systemd's logging
elsewhere.
With this fix we initially always log to kmsg now, if we are PID1, and
only after parsing the kernel cmdline try to open the journal if that's
desired.
(The effective benefit of this is that SELinux performance data is now
logged again to kmsg like it used to be.)
Previously, if X allocated all 6 TTYs (for multi-session for example) no
getty would be available anymore to guarantee console-based logins.
With the new ReserveVT= switch in logind.conf we can now choose one VT
(6 by default) that will always be subject to autovt-style activation,
i.e. we'll always have a getty on TTY6, and X will never take possession
of it.
Lennart Poettering