Instead of the /dev/.run trick we have currently implemented, we decided
to move the early-boot runtime dir to /run.
An existing /var/run directory is bind-mounted to /run. If /var/run is
already a symlink, no action is taken.
An existing /var/lock directory is bind-mounted to /run/lock.
If /var/lock is already a symlink, no action is taken.
To implement the directory vs. symlink logic, we have a:
ConditionPathIsDirectory=
now, which is used in the mount units.
Skipped mount unit in case of symlink:
$ systemctl status var-run.mount
var-run.mount - Runtime Directory
Loaded: loaded (/lib/systemd/system/var-run.mount)
Active: inactive (dead)
start condition failed at Fri, 25 Mar 2011 04:51:41 +0100; 6min ago
Where: /var/run
What: /run
CGroup: name=systemd:/system/var-run.mount
The systemd rpm needs to make sure to add something like:
%pre
mkdir -p -m0755 /run >/dev/null 2>&1 || :
or it needs to be added to filesystem.rpm.
Udev -git already uses /run if that exists, and is writable at bootup.
Otherwise it falls back to the current /dev/.udev.
Dracut and plymouth need to be adopted to switch from /dev/.run to run
too.
Cheers,
Kay
Now that we have /dev/.run there's no need to use abstract namespace
sockets. So, let's move things to /dev/.run, to make things more easily
discoverable and improve compat with chroot() and fs namespacing.
During early boot, mount a tmpfs to /dev/.run and then bind mount it to
/var/run as soon as /var is available.
This makes it possible for programs involved in early boot to put
runtime data in /dev/.run which later on will show up in /var/run like
any other.
This can be used to solve the early-boot D-Bus problem: D-Bus may start
up with its socket bound to /dev/.run/dbus/system_bus_socket and after
/var it will also be available under the traditional name
/var/run/dbus/system_bus_socket.
This also is intended to be used as a better place for systemd, mount,
mdadm, blkid, plymouth, bootchart and dracut runtime data, which is
currently stored in various places in /dev/.xxx.
This merges several separate patches that I carry as part of
Mandriva systemd RPM. They touch those parts that are very
unlikely to be changed in near future and do not impose any
functionality change for systemd core. I also think it is
useful for troubleshooting to have real distribution name in
system logs, espicially when someone reports problem upstream.
The patch looks bigger than sum of replaced patches because
- previous patches were applied on top of distro=fedora, now
I need to add all those bits for distro=mandriva as well
- part of patch was done as spec file magic, but it seems more
logical to ship all these bits together
On the console indian characters cannot be displayed, hence it is
advisable to disable indian locales on the console, which most
distributions traditionally did from a shell fragment executed post
login. If getty gets started with locale settings passed it would itself
however be translated without the no-indian-on-console fixup applied.
Hence, for now don't pass any locale settings to getty/login, and thus
rely on the classic post-login script fragment to set and fix the
locale.
Eventually we probably want to drop this again since the system locale
should be read and set at one place, and not at multiple, and that one
place should be PID 1.
https://bugzilla.redhat.com/show_bug.cgi?id=663900
TERM=vt100-nav was necessary for compat with some ppc hvc devices, a
long time ago. Unfortunately vt100-nav terminfo is not installed by
default on most distros, hence change the default to v100 which is
available universally and still should be a relatively safe and
conservative default.
Should it turn out that vt100 is not really the best choice we can
revert this change again and then ask distros to move vt100-nav into
their default install.
That unity pulls in OpenRC which in turn pulls in most of legacy
system that causes lots of troubles as it is too smart, thus not
recommended.
Moreover, SystemD developers seems to agree that a service file per DM
is the best approach, so having gdm.service, kdm.service, slim.service
is better than a single wrapper for them.
