Am 06.10.2012 05:42, schrieb Kok, Auke-jan H: > On Fri, Oct 5, 2012 at 4:11 PM, Thomas Bächler <tho...@archlinux.org> wrote: >> Running as a user instance won't work at all if systemd isn't running as >> system >> manager, so refuse to start in that case. > > huh? > > I'd like to think this is a situation that should really work...
It doesn't work, but it doesn't say so. > - to test systemd in a non-systemd environment > - Chroot/namespacesVM situations where there's no contact with the > real init process > - some calamity happened or IPC is temporarily offlined > - just because it makes no sense to enforce it > > what exactly breaks? In the namespace situation (you are likely talking about nspawn or lxc), we are PID 1 and should never hit that code path. I tried running systemd as a user on a non-systemd system because I thought it should work. It first complains that it cannot set up its cgroups - I don't know if that problem can be solved, but I think it can't (you need root to configure the main systemd cgroup, I think). Furthermore, systemctl was unable to do anything - not even 'systemctl --user exit' worked - it couldn't find systemd on the bus, as it refuses to look for the bus unless sd_booted() is true. You can send the signal manually, but that is not what you want. The situation gets worse: You can only kill the systemd instance with kill -9 - both kill -15 and Ctrl+C result in an error message about dbus. As systemctl refuses to any work (except enable/disable) when sd_booted() == false, so should systemd --user - this patch merely makes systemd's behaviour consistent.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
