xpra --start-child xterm starts in / and does not respect .Xresources

[totaam]

Issue migrated from trac ticket # 1114

component: android | priority: major | resolution: fixed

2016-02-08 00:40:58: anntzer created the issue

---

All's in the title: after

xpra start ssh:username@server:100 --start-child xterm

xterm starts in / (root) (I'd expect starting in $HOME instead) and uses a white background, even though my .Xresources (which work fine locally) specify otherwise.

Arch Linux regular package, xpra 0.16.1.

[totaam]

2016-02-08 06:54:10: antoine changed status from new to assigned

[totaam]

2016-02-08 06:54:10: antoine edited the issue description

[totaam]

2016-02-08 06:54:10: antoine commented

---

You can get the Xresources applied by running:

xpra start ssh:localhost --start-child xterm --start='xrdb -merge ~/.Xresources'

And obviously, you can achieve the same thing by adding this line to your /etc/xpra/xpra.conf:

start = xrdb -merge ~/.Xresources

Or use a session script or whatever. r11884 now includes an xrdb example in the default config file.

I am not convinced that it is xpra's job to choose what gets applied and what doesn't.
Especially in this case where the client's xrdb does get synchronized already. Whatever xrdb settings I have on the client do get applied in the server session, just too late for start-child which gets run as soon as the server starts. If I start another xterm from the initial xterm, I see that the settings have been applied.

It would be nice if we waited for the client to connect and apply its settings (xdb, dpi, screen resolution, keyboard settings, etc) before executing the start / start-child commands. Or at least have the option to do that.

Maybe a --start-after-connect flag, which would be set automatically when using ssh start, since we know that the client will be connecting. (though we would need to do this via an environment variable instead of a command line because when the client generates the remote command line, it has no way of knowing if the server is going to support newer command line options..)

---

As for the current working directory being "/", this one is caused by the daemonize code which calls chdir("/").
I didn't want to just remove that line as this is what every other daemon code does.. So r11885 saves the cwd before daemonizing and uses it when starting commands. This will be backported to older versions. (the start-after-connect change, if I ever get around to it, will not)

[totaam]

2016-02-08 08:28:10: anntzer commented

---

xpra start ssh:localhost --start-child xterm --start='xrdb -merge ~/.Xresources'

works and is a reasonable workaround for now, although I'm a bit confused as to why the commands seem to be executed in reverse order (i.e.,

xpra start ssh:localhost --start='xrdb -merge ~/.Xresources' --start-child xterm

doesn't).

I do vote in favor of "--start-after-connect", which makes sense as you say.

On a side note, in the xpra man page, the SYNOPSIS entry for "xpra start" does not list the "--start" option (just the "--start-child" one).

[totaam]

2016-02-17 15:15:40: antoine changed status from assigned to new

[totaam]

2016-02-17 15:15:40: antoine changed owner from antoine to anntzer

[totaam]

2016-02-17 15:15:40: antoine commented

---

start-after-connect implemented in r11972.

@anntzer: please close if this works for you.

[totaam]

2016-02-18 23:08:32: anntzer commented

---

Latest SVN version (both on the server and the client) actually segfaults for me, regardless of whether I pass --start-after-connect or not.

[totaam]

2016-02-19 02:33:32: antoine commented

---

segfaults for me...
[[BR]]
Do you have any debug output or gdb backtrace?
I obviously cannot reproduce this.

[totaam]

2016-02-19 03:04:38: anntzer commented

---

Here we go

(gdb) r /usr/bin/xpra start ssh:antony@maxwell:100 --start-child xterm
Starting program: /usr/bin/python2 /usr/bin/xpra start ssh:antony@maxwell:100 --start-child xterm
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7de40b0 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0  0x00007ffff7de40b0 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#1  0x00007ffff7de4d3f in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#2  0x00007ffff7de6985 in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2
#3  0x00007ffff7dee7b9 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#4  0x00007ffff7dea124 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#5  0x00007ffff7dedfd1 in _dl_open () from /lib64/ld-linux-x86-64.so.2
#6  0x00007ffff723dfc9 in ?? () from /usr/lib/libdl.so.2
#7  0x00007ffff7dea124 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#8  0x00007ffff723e5e1 in ?? () from /usr/lib/libdl.so.2
#9  0x00007ffff723e061 in dlopen () from /usr/lib/libdl.so.2
#10 0x00007ffff7b230de in _PyImport_GetDynLoadFunc () from /usr/lib/libpython2.7.so.1.0
#11 0x00007ffff7b0945f in _PyImport_LoadDynamicModule () from /usr/lib/libpython2.7.so.1.0
#12 0x00007ffff7b0740c in import_submodule () from /usr/lib/libpython2.7.so.1.0
#13 0x00007ffff7b07959 in ensure_fromlist () from /usr/lib/libpython2.7.so.1.0
#14 0x00007ffff7b081ce in PyImport_ImportModuleLevel () from /usr/lib/libpython2.7.so.1.0
#15 0x00007ffff7ae873c in builtin___import__ () from /usr/lib/libpython2.7.so.1.0
#16 0x00007ffff7a4efe7 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#17 0x00007ffff7aea61b in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.7.so.1.0
#18 0x00007ffff7aed97f in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#19 0x00007ffff7af5393 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#20 0x00007ffff7af54cc in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0
#21 0x00007ffff7b063e4 in PyImport_ExecCodeModuleEx () from /usr/lib/libpython2.7.so.1.0
#22 0x00007ffff7b0667d in load_source_module () from /usr/lib/libpython2.7.so.1.0
#23 0x00007ffff7b07c50 in load_package () from /usr/lib/libpython2.7.so.1.0
#24 0x00007ffff7b0740c in import_submodule () from /usr/lib/libpython2.7.so.1.0
#25 0x00007ffff7b0768f in load_next () from /usr/lib/libpython2.7.so.1.0
#26 0x00007ffff7b08107 in PyImport_ImportModuleLevel () from /usr/lib/libpython2.7.so.1.0
#27 0x00007ffff7ae873c in builtin___import__ () from /usr/lib/libpython2.7.so.1.0
#28 0x00007ffff7af22be in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#29 0x00007ffff7af1fbd in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#30 0x00007ffff7af1fbd in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#31 0x00007ffff7af1fbd in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#32 0x00007ffff7af1fbd in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#33 0x00007ffff7af5393 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#34 0x00007ffff7af54cc in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0
#35 0x00007ffff7b104f3 in run_mod () from /usr/lib/libpython2.7.so.1.0
#36 0x00007ffff7b117a2 in PyRun_FileExFlags () from /usr/lib/libpython2.7.so.1.0
#37 0x00007ffff7b12ad9 in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.7.so.1.0
#38 0x00007ffff7b25b05 in Py_Main () from /usr/lib/libpython2.7.so.1.0
#39 0x00007ffff7461610 in __libc_start_main () from /usr/lib/libc.so.6
#40 0x0000555555554859 in _start ()

[totaam]

2016-02-19 03:08:16: antoine commented

---

@anntzer: this is not related to this ticket and is very likely to be something caused by Arch - there is not one line related to xpra in this whole backtrace.

[totaam]

2016-02-22 14:07:50: antoine changed owner from anntzer to afarr

[totaam]

2016-02-22 14:07:50: antoine commented

---

I was playing with start and start-after-connect as part of #1132 and I didn't like the limitations of the implementation in r11972. So r12009 generalizes it and allows 6 different start options:

• start / start-child, as before
• start-after-connect / start-child-after-connect, commands started when the first client connects
• start-on-connect / start-child-on-connect, every time a client connects

And we now expose this and more via xpra info too.
Here's an example I used for testing:

xpra start :100 --daemon=no --bind-tcp=0.0.0.0:10000 \
    --start-child="xterm -bg yellow" \
    --start-after-connect="xterm -bg red" \
    --start-child-on-connect="xterm -bg green" \
    --exit-with-children

You will get a yellow, a green and a red xterm when you connect. A new green one will be started every time you connect. Exiting the yellow and all the green ones will terminate the session.
And here's the xpra info for it:

$ xpra info | grep ^commands
commands.exit-with-children=True
commands.start=()
commands.start-after-connect=('xterm -bg red',)
commands.start-after-connect-done=True
commands.start-child=('xterm -bg yellow',)
commands.start-child-after-connect=()
commands.start-child-on-connect=('xterm -bg green',)
commands.start-new=False
commands.start-on-connect=()

@afarr: I believe the stacktrace in comment:6 is bogus / not caused by xpra, so this is a FYI (not sure you can find a use for it) - feel free to close.

[totaam]

2016-05-19 01:36:21: afarr changed status from new to closed

[totaam]

2016-05-19 01:36:21: afarr set resolution to fixed

[totaam]

2016-05-19 01:36:21: afarr commented

---

Wow... it's like xterm Christmas!

Looks good, and some of these options may be very useful to know about.

Closing.