Can not start server

[totaam]

Issue migrated from trac ticket # 1536

component: server | priority: major | resolution: fixed

2017-06-05 19:09:39: psycho_zs created the issue

---

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 ''

[totaam]

2017-06-05 20:02:26: antoine changed owner from antoine to psycho_zs

[totaam]

2017-06-05 20:02:26: antoine commented

---

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..

[totaam]

2017-06-05 20:37:15: psycho_zs commented

---

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.

[totaam]

2017-06-05 20:48:56: antoine commented

---

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.

[totaam]

2017-06-05 21:14:30: psycho_zs commented

---

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

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

[totaam]

2017-06-05 21:25:51: antoine commented

---

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.

[totaam]

2017-06-05 21:32:51: psycho_zs commented

---

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 ''

[totaam]

2017-07-15 06:04:08: antoine commented

---

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

[totaam]

2017-07-15 08:02:42: psycho_zs commented

---

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-runauto it still can not tell that there is no systemd bus in ssh sesssion and fails.

[totaam]

2017-07-15 12:55:33: antoine commented

---

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?

[totaam]

2017-07-15 13:57:23: psycho_zs changed status from new to closed

[totaam]

2017-07-15 13:57:23: psycho_zs set resolution to fixed

[totaam]

2017-07-15 13:57:23: psycho_zs commented

---

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.

[totaam]

2017-07-15 14:27:49: antoine commented

---

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: #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?)

[totaam]

2017-07-15 16:06:27: psycho_zs commented

---

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.

[totaam]

2017-09-11 18:21:25: antoine commented

---

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.

[totaam]

2020-02-11 04:32:58: antoine commented

---

See also #2585, #1105, ...