On 2018/06/28 08:47, Sebastien Marie wrote: > > I think last patch on firefox workarounded efficiently fork+exec > problem (setting DBUS_SESSION_BUS_ADDRESS if not present). so no wrapper > script should be needed. > > So reenabling autolaunch on dbus port is possible and should not impact > firefox. > > On the other side, it only hides the underline problem of dbus session. > If I correctly understood have dbus-launch works, When a program starts > it at program level (opposite to Xsession level), the session is only > "local" to the program: only this particular program will speak with > this dbus daemon. And it could result on starting a dbus session per > program that could need it. I have already seen several dbus deamon > running because starting several firefox -no-remote.
Even if we're going to make changes in Xsession I think we should reenable autolaunch in dbus for now as there is too much hard-to-debug breakage. > The proper fix would be changing /etc/X11/xenodm/Xsession. But it should > be done in proper way. Personally I would be in favor of generic code to > load (shell sourcing) files in /etc/X11/xenodm/Xsession.d directory, > with mecanism a-la "rcctl enable" to know which files are explicitly > asked for inclusion. > > So dbus port would provide a /etc/X11/xenodm/Xsession/dbus.script file, > and administrator would have to enable the inclusion of the file for > make it sourced by /etc/X11/xenodm/Xsession.d Anything that the administrator has to do themselves is going to result in the same problem. If people were already following dbus' pkg-readme then we wouldn't have had any problems with disabling autolaunch..
