xpra icon
Bug tracker and wiki

Opened 15 months ago

Closed 13 months ago

Last modified 11 months ago

#1536 closed defect (fixed)

Can not start server

Reported by: psycho_zs Owned by: psycho_zs
Priority: major Milestone: 2.1
Component: server Version: trunk
Keywords: Cc:

Description

I wanted to test latest xpra.
Tried latest deb build (2.1-20170409r15542-1), it gave error on server start:

$ xpra start :100 
using systemd-run to wrap 'start' server command
'systemd-run' '--description' 'xpra-start' '--scope' '--user' '/usr/bin/xpra' 'start' ':100' '--systemd-run=no'
Failed to create bus connection: No such file or directory

So it tried to run systemd-run despite using '--systemd-run=no'?

Tried to build a package from latest SVN, r16022, it gave the same error.

I edited xpra/scripts/main.py with line:

SYSTEMD_RUN = envbool("XPRA_SYSTEMD_RUN", False)

and built again. This time there is a problem with display:

$ xpra start :100 -d all
2017-06-05 21:08:35,945 get_enabled_encoders(['bencode', 'rencode', 'yaml']) enabled=['yaml', 'rencode', 'bencode']
2017-06-05 21:08:35,945 get_enabled_encoders(['bencode', 'rencode', 'yaml']) enabled=['yaml', 'rencode', 'bencode']
2017-06-05 21:08:35,945 get_enabled_encoders(['bencode', 'rencode', 'yaml']) enabled=['yaml', 'rencode', 'bencode']
2017-06-05 21:08:35,945 get_enabled_encoders(['bencode', 'rencode', 'yaml']) enabled=['yaml', 'rencode', 'bencode']
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display
  warnings.warn(str(e), _gtk.Warning)
2017-06-05 21:08:36,003 run_mode error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 176, in main
    return run_mode(script_file, err, options, args, mode, defaults)
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 1329, in run_mode
    r = run_client(error_cb, options, args, "request-%s" % mode)
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 2272, in run_client
    app = make_client(error_cb, opts)
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 2324, in make_client
    toolkit_module = __import__(client_module, globals(), locals(), ['XpraClient'])
  File "/usr/lib/python2.7/dist-packages/xpra/client/gtk2/__init__.py", line 13, in <module>
    from xpra.x11.gtk2 import gdk_display_source
  File "xpra/x11/gtk2/gdk_display_source.pyx", line 88, in init xpra.x11.gtk2.gdk_display_source (xpra/x11/gtk2/gdk_display_source.c:1879)
  File "xpra/x11/gtk2/gdk_display_source.pyx", line 78, in xpra.x11.gtk2.gdk_display_source.init_gdk_display_source (xpra/x11/gtk2/gdk_display_source.c:1304)
InitException: cannot access the default display ''
InitException: cannot access the default display ''
xpra initialization error:
 cannot access the default display ''

Change History (13)

comment:1 Changed 15 months ago by Antoine Martin

Owner: changed from Antoine Martin to psycho_zs

So it tried to run systemd-run despite using '--systemd-run=no'?

Your command line does not include systemd-run=no.

Failed to create bus connection: No such file or directory

This usually comes from "systemd-run", not xpra.

I edited xpra/scripts/main.py with line:

Don't edit anything, just set the environment variable, ie:

XPRA_SYSTEMD_RUN=0 xpra ..

cannot access the default display ''

I'm not seeing that here.
There was a bug related to #1105, fixed in r16023.
If the problem persists, try running with --start-via-proxy=no, or make sure you start the system-wide proxy server:

systemctl start xpra.socket

(see #1105 for more details)

Please always specify your OS, version, etc..

comment:2 Changed 15 months ago by psycho_zs

This usually comes from "systemd-run", not xpra.

I'm running it via ssh, there is no bus available in such sessions. What is the point of systemd-run=auto then?

Built package does not contain xpra.socket unit. I tried to add lib/systemd/system/* to xpra.install, but it does not work this way.

At least with --systemd-run=no --start-via-proxy=no xpra launches.

comment:3 Changed 15 months ago by Antoine Martin

I'm running it via ssh, there is no bus available in such sessions. What is the point of systemd-run=auto then?

systemd-run doesn't require dbus on my Fedora system. I can run:

systemd-run --user /bin/true

From a fresh ssh login, no dbus processes anywhere.

Problem is that we want systemd-run in case the system wide proxy server is not available. And I have no idea how to check that systemd-run is going to fail.. Ideas welcome.

Built package does not contain xpra.socket unit. I tried to add lib/systemd/system/* to xpra.install, but it does not work this way.

Looks like you are on a Debian distro of some sort. No-one knows how to package the systemd bits for Debian (the documentation is unhelpful - does not explain the magic that goes on behind the scenes): #1530

At least with --systemd-run=no --start-via-proxy=no xpra launches.

As of r16023, start-via-proxy=no should not be needed.

comment:4 Changed 15 months ago by psycho_zs

As of r16023, start-via-proxy=no should not be needed

I've built r16024 and --start-via-proxy=no is still needed

comment:5 Changed 15 months ago by Antoine Martin

I've built r16024 and --start-via-proxy=no is still needed

It should be impossible to hit the original error in the ticket description (line 1329, in run_mode...) since we now catch the exception and try to continue unless start-via-proxy is set to ON.
Please post the new error you are seeing.

As per comment:1, Please always specify your OS, version, etc.. so I can try to reproduce.

comment:6 Changed 15 months ago by psycho_zs

Debian stretch, amd64.
Xpra 2.1-r16024

$ xpra start :100 --systemd-run=no -d all
2017-06-05 23:30:20,386 get_enabled_encoders(['bencode', 'rencode', 'yaml']) enabled=['yaml', 'rencode', 'bencode']
2017-06-05 23:30:20,386 get_enabled_encoders(['bencode', 'rencode', 'yaml']) enabled=['yaml', 'rencode', 'bencode']
2017-06-05 23:30:20,386 get_enabled_encoders(['bencode', 'rencode', 'yaml']) enabled=['yaml', 'rencode', 'bencode']
2017-06-05 23:30:20,386 get_enabled_encoders(['bencode', 'rencode', 'yaml']) enabled=['yaml', 'rencode', 'bencode']
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display
  warnings.warn(str(e), _gtk.Warning)
Warning: cannot use the system proxy for 'start' subcommand,
 cannot access the default display ''

comment:7 Changed 13 months ago by Antoine Martin

I cannot reproduce with any of the latest beta builds. What am I missing?

comment:8 Changed 13 months ago by psycho_zs

With 2.1-20170712r16303-1 xpra start :100 --systemd-run=no works.
With default start-via-proxy = auto xpra successfully detects missing proxy, but with systemd-run = auto it still can not tell that there is no systemd bus in ssh sesssion and fails.

comment:9 Changed 13 months ago by Antoine Martin

With a fresh stretch VM booted up to multi-user, I can login via ssh and run:

systemd-run --scope --user ls -la

What am I missing?

How do I get an ssh shell without the "systemd bus" as you call it?

comment:10 Changed 13 months ago by psycho_zs

Resolution: fixed
Status: newclosed

It appears there's been some changes with systemd's classic overcomplicated shenanigans. To get systemd bus in ssh sessions, there should be libpam-systemd package installed. It quietly came as a dependency to something, probably somewhere before stretch release, so now I indeed have systemd bus in ssh sessions on the server (the initial issue with Failed to create bus connection: No such file or directory no longer applies here and systemd-run = auto indeed seems to be working as it should. I can not test for sure without libpam-systemd because now it apparently takes out a chunk of the system on the way out.

Now there is a bug with systemd 233 in testing which can not launch anything in user scopes. But that is a different story.

comment:11 Changed 13 months ago by Antoine Martin

Now there is a bug with systemd 233 in testing which can not launch anything in user scopes. But that is a different story.

Maybe this one? 3388 : systemd-run --user --scope ... doesn't work with unified cgroup hierarchy

We've tracked it here: ticket:1105#comment:14, and had to disable "systemd-run" in Fedora 26+.
Do I need to do the same thing for Debian Testing? (and how would I check for that?)

comment:12 Changed 13 months ago by psycho_zs

Maybe this one?

Seems to be the one.

I do not yet understand what was enabled and where. And what problem these people were trying to solve by creating all this mess in the first place.

Last edited 13 months ago by psycho_zs (previous) (diff)

comment:13 Changed 11 months ago by Antoine Martin

It seems that with kernel 4.11 and later, the Fedora 26 issue from comment:11 is gone.
The big problem is that we generate the config at build time, and we have no way of knowing at that time if the runtime combination of systemd + kernel is going to work.
r16826 undoes r15990 to re-enable systemd-run on Fedora 26. Let's hope for the best.

Note: See TracTickets for help on using tickets.