On Fri, 02 Dec 2016 at 13:58:01 +0530, Mohan R wrote: > Let say if a user already have a session(session0) in a seat (customseat0) and > he want to start another session in another seat (customseat1).
Does this mean your user is trying to be physically present in two places at the same time? How is this a useful thing to do? :-) > Is there any way to make pam_systemd provides uniq DBUS_SESSION_BUS_ADDRESS > for > every session (may be unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)? or is > there any way to ask 'systemd --user' to provide different > DBUS_SESSION_BUS_ADDRESS to the childs? More background on user-sessions in general: https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html pam_systemd does not do this unless you have configured dbus-daemon to provide one bus per logind user-session (./configure --enable-user-session), which is not the default. Either you or your OS vendor have explicitly chosen this model: if that doesn't match your requirements, you need to revert this choice. If you require multiple D-Bus sessions per logind user-session, you must either configure dbus without --enable-user-session (the default is equivalent to --disable-user-session), or mask or remove the dbus.service and dbus.socket systemd user units that are installed by enabling that option (/usr/lib/systemd/dbus.*). The user-session support in dbus is designed to be easy to enable or disable by adding/removing packages, if your OS vendor packages it suitably. For example, in Debian (including derivatives like Ubuntu), /usr/lib/systemd/dbus.* are packaged separately in the dbus-user-session package, so you can remove that package to go back to the older model. If your OS vendor has not packaged dbus like that, perhaps ask them to look at how it's done in Debian? Or if they have deliberately chosen not to support multiple D-Bus sessions per logind user-session, then that OS distribution is not suitable for your requirements, and you need to change either your requirements or your OS distribution. Regards, S _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
