xpra icon
Bug tracker and wiki

Opened 4 months ago

Closed 2 months ago

Last modified 9 days 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 4 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 4 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 4 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 4 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 4 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 4 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 2 months ago by Antoine Martin

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

comment:8 Changed 2 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 2 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 2 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 2 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 2 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 2 months ago by psycho_zs (previous) (diff)

comment:13 Changed 9 days 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.