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..
No comments:
Post a Comment