#1104 closed enhancement (fixed)
start the dbus server automatically
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | critical | Milestone: | 0.17 |
Component: | server | Version: | trunk |
Keywords: | dbus | Cc: |
Description
A number of features rely on having a dbus server running:
- the dbus interface obviously #904
- notifications forwarding
- dbus-forwarding
etc...
The user may also have an existing dbus server running in their desktop session, but using this one can cause serious problems (ie: maybe #1032)
The usual way of working around this is to start the xpra server with:
dbus-launch xpra ..
A better way would be to automatically start the dbus server as part of xpra, through a command line switch and config option which would be enabled by default.
Change History (8)
comment:1 Changed 5 years ago by
Owner: | changed from Antoine Martin to alas |
---|
comment:2 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Seems to be working as advertised... I'll go ahead and close.
comment:3 Changed 5 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Just as a note... after leaving a server running for a few days, when I shut it down with a control-c, I got the following dbus errors:
2016-02-08 10:47:34,840 got signal SIGINT, exiting 2016-02-08 10:47:34,847 Disconnecting client '10.0.11.162:59620': 2016-02-08 10:47:34,847 server shutdown 2016-02-08 10:47:34,874 xpra client disconnected. 2016-02-08 10:47:34,876 child 'xterm' with pid 25094 has terminated 2016-02-08 10:47:34,877 failed to release dbus notification forwarder: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. 2016-02-08 10:47:34,877 child 'xterm' with pid 25097 has terminated Exception dbus.exceptions.DBusException: DBusException('Connection is closed',) in <bound method BusName.__del__ of <dbus.service.BusName org.xpra.Server13 on <dbus._dbus.SessionBus (session) at 0x7f2be9aef650> at 0x7f2bdcc79910>> ignored
The server did shut down ok, and restarted fine though, so maybe it was just the dbus server being shut down before it could respond... Was running a 0.16.2 r11850 win32 client against a 0.16.2 r11850 fedora 23 server.
Reopening the ticket, in case this isn't just an expected signint issue.
comment:4 Changed 5 years ago by
Owner: | changed from alas to Antoine Martin |
---|---|
Status: | reopened → new |
comment:5 Changed 5 years ago by
Priority: | major → critical |
---|---|
Status: | new → assigned |
The DBusException
from comment:3 is unlikely to be a big problem.
There is a bigger problem though: using xpra exit
, the dbus daemon inherits the socket from the parent process so we cannot start a new server using the same port with --use-display
.
comment:6 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 Changed 5 years ago by
Since we now have a dbus server started by default, I have enabled dbus in pulseaudio by default: r12139
comment:8 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1104
Done in r11784.
What this changes:
@afarr: mostly a FYI.