Hi, On 01.12.19 23:24, Simon McVittie wrote: > dbus-user-session is not, and probably will not be, usable on non-systemd > systems. If per-user service managers other than `systemd --user` exist > and can be configured to provide equivalent semantics, I'd be happy > to review the necessary integration files, but at the moment there > is no way to have the semantics represented by dbus-user-session on a > non-systemd system. Yes, I feel pretty confident in predicting that this interface will not be implemented by alternative implementations. The objections to systemd that I've heard so far are with the design, not the implementation, and the semantics of this interface only work with this particular design. >>> It wouldn't be a problem in practice to break that dependency chain, as >>> systemd based installations tend not to be curated on a >>> package-by-package basis > It's true that non-systemd-based installations need to be curated to > remain non-systemd-based; and it's true that because systemd is the > default init, systems that accept defaults will be systemd-based and > not strongly curated; but I don't think either of those implies that > there are no strongly curated systemd-based systems. Not "none", but I wouldn't expect the average systemd user to deinstall "dbus-user-session" because it looks unnecessary. The average sysvinit user on the other hand... :) > These categories exist: > * No service manager at all > - typical for Docker (pid 1 is usually a simple process reaper) > - typical for chroots (pid 1 is outside the chroot) > - systemd --user isn't run > - dbus-user-session doesn't work > * Various non-systemd service managers (sysv-rc, OpenRC, etc.) > - systemd --user isn't run > - dbus-user-session doesn't work > * systemd as pid 1, but no pam_systemd > - systemd --user isn't run > - dbus-user-session doesn't work > * systemd as pid 1, and pam_systemd is used > - typical for "full" systems (bare metal, VM, lxd) > - systemd --user is run > - dbus-user-session works Wasn't there a plan to add support for containers managed through systemd that have filtered access to the system dbus, or is that just a special case of a service unit? Simon
Attachment:
signature.asc
Description: OpenPGP digital signature