Shared publicly  - 
It's really nice when dbus crash on a +systemd started system, the desktop (kde) obviously is broken but you loose the console too.
Why? because system start them on demand, but cannot work w/o dbus so Ctrl+Alt+F2 bring you to nowhere ...
Ctrl+Alt+Canc? No way systemd is locked
Solution? Hard reboot, if the kernel is compiled with some magic press Ctrl+print+S for an emergency sync of the disk, followed by Ctrl+print+B to reboot.
How it happened? Trying to port the gentoo linux-vserver start scripts, which mess with containers /probably/.
What systemd should do? It should start at least one getty for a console at boot_time, always, the other could still be optional.
And yes this mean that I'm trying systemd, sigh.
Fabio Erculiani's profile photoFrancesco Riosa's profile photoDavid Timothy Strauss's profile photo
The configuration of consoles as persistent or on-demand is a distribution's decision, not systemd's.
in opensource everything is a distrbution decision, it's the power of open source, you can modify it.
However gentoo try to keep modifications to a minimum. I'm quite confident the default is to have them on demand, seem also to remember a post from Lennart where he wrote consoles are not needed on a modern system (or something like that)
Adding a service for a persistent console is no more a break from upstream than installing a service to run Apache. You could even make it available as a separate package that adds the service file (which could run getty on its own or "depend" on starting an instance of the bundled service).

That said, I haven't seen a problem with DBus crashing and leaving systemd in a zombie state, and I run Fedora on both of my laptops and hundreds of servers. Are DBus crashes common for you?
No, dbus crashes are not common at all, the most likely reason there where problems is because of interferences with a service that mess with containers ¹.
The point is openrc (or any other init system) never ever left me with a totally uncontrollable system, either a console or sshd would work, an hard reboot is a rare thing in the linux world.
¹ linux-vservers is a patch for the linux kernel, enabling something like a chroot on steroid. Faster than full virtualization but still good at separting systems.
If you're interested in lightweight containers, check out systemd's nspawn, too. It's getting quite a bit of work these days.
+David Strauss 
Actually is rather difficult to make me happy ;)
Also this is another "before going to sleep post" read with safety gloves.
Last thing first, if sending SIGSEGV to dbus is the only way to kill it then systemd should avoid to do that. But I've yet to debug it and let's give it the benefit of a doubt.
It's easy to understand why dbus cannot be simply restarted, it's implied in it's security mechanism.
It's not even bad to rely on it for desktops, we know that if it die the desktop is dead anyway. For servers the additional complexity should be avoided instead, but let say we can live with it.
Having dbus in the kernel provoke in me very mixed feelings, it can benefit desktops a lot, even w/o systemd but there can be also bad things attached, security and stability related. Moving the daemon at ring 0 probably isn't that easy because it's already some time they're trying. No happynes there until I see it stable and tested.
Also I didn't know logind didn't work w/o dbus (as Lennart mail seem to imply) that sound no good
> Also I didn't know logind didn't work w/o dbus (as Lennart mail seem to imply) that sound no good

Why did you think the console fails after a D-Bus crash?
to clarify:
if consoles are set as "persistent" (referring to a previous comment), the user could login after a dbus crash?
Yes. A crash of D-Bus should not cause systemd to tear down any services already running.
I wonder if there's any gentoo-dev working on improving the integration with systemd. I'd like to arrange a small team that aims to make systemd really work. Yes, this means that I tried systemd and I've found several important integration issues after the first 30 minutes.
some examples? Integration often is easy after the issues have been pointed out
1. setup a migration tool that, where possible, configures systemd units according to previous openrc runlevel scripts.
2. some systemd units just don't work, the most interesting one is sshd, which fails if host keys have not been generated.
3. the sematics of USE=systemd is ambiguous. Some developers don't use it, others use it to install optional units, others use it to enable/disable configure flags. The problem should be addressed (create more USE flags, make them global? Just saying)
4. Many pkgs installing init scripts don't have systemd units

GNOME 3.8 is going to depend against systemd in a more radical way than 3.6 and probably at some point in future, ConsoleKit and Upower support will be removed, so we would be either left with implementing our own systemd->openrc bridge or reverting upstream commits.
I am just concerned that we should at least be ready to deal with the apocalypse.
1. "Runlevel" support in systemd is handled by the target system. The good news is you can name them whatever you like and have as many as you want. Still, systemd-based distros usually don't have many because systemd supports explicit dependencies between services and other units.
2. Automatic generation of host keys should be a simple addition to the sshd service. Typically, the best way is to have sshd.service include a directive like ExecStartPre=/usr/sbin/sshd-keygen.
3. I'm not too sure about this problem. It seems distro-specific.
4. This should not be an immediate problem, as systemd has full support for init scripts, including LSB metadata about default runlevels for enabling the service. You can even do a pseudo-transition by configuring a "native" service that executes the init script as the handler for startup, shutdown, and reloads. This sort of "native" service is how Fedora initially transitioned iptables to systemd.
+Fabio Erculiani +David Strauss 
1) a gut feeling is that migration is not contemplated, systemd suppose to be started from a systemd box, even documentation only use systemd commands that can only be used by systemd. Not something that can be achieved now (too much work).
2)  maybe script expect an already configured system. if systemd has conditional execution, based on file existance maybe a bash script could be called without a fork in the common case.
Anyway, yes it's generally a mess, for Sabayon you could create a package that contain them all, need some thinking
3) consensus was "systemd" use flag is used only for incompatible (with openrc fex) changes to the package, the units are always installed.
everything else is likely a bug
4) this indeed is a big problem, since systemd cannot run openrc scripts, see point 2) about managing everything in a centralized package.

I'm happy to be a kde user if gnome is shooting himself in the foot like that :D
2. Yes, it's possible to do conditional execution based on an existence check, but it would have to happen in a separate service that sshd depends on.
Add a comment...