Wrong keyboard setting when resume NX session

[Rogerio Bastos]

I'm using winswitch 0.12.14 in server and client-side, and NX protocol to open Desktop sessions. However, every time I resume a session the keyboard settings is not set and I need to execute the following command to fix:

$ setxkbmap -layout us -variant alt-intl -print | xkbcomp - $DISPLAY

[Rogerio Bastos]

Attached part of server log. I think the relevant parts are:

No protocol specified
Error:            Cannot open display ":61"
                  Exiting

[EE] 2012/13/08 14:00:16 xmodmap_util.exec_xmodmap({'LANG': 'en_US.UTF-8', 'TERM': 'screen', 'SHELL': '/bin/bash', \
    'TMUX_PANE': '%0', 'SHLVL': '2', 'SSH_TTY': '/dev/pts/1', 'SSH_CLIENT': '10.1.0.70 57193 22', \
    'TMUX': '/tmp/tmux-1074/default,5233,0', 'HISTCONTROL': 'ignoreboth', 'PWD': '/home/neptuno/rogeriobastos', \
    'LOGNAME': 'rogeriobastos', 'USER': 'rogeriobastos', 'PATH': '/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games', \
    'MAIL': '/var/mail/rogeriobastos', 'LS_COLORS': '...', 'HOME': '/home/neptuno/rogeriobastos', 'DISPLAY': ':61', \
    '_': '/usr/bin/winswitch_server', 'SSH_CONNECTION': '10.1.0.70 57193 10.1.0.17 22'},-pm) \
    process terminated with error code 1, stdout=, stderr=No protocol specified/usr/bin/xmodmap:  unable to open display ':61'

[Rogerio Bastos]

Also there is many defunct kill processes. They are children of the winswitch_server.

$ ps aux | grep kill
1074      5923  0.0  0.0      0     0 pts/2    Z+   Aug13   0:00 [kill] <defunct>
1074      6805  0.0  0.0      0     0 pts/2    Z+   Aug13   0:00 [kill] <defunct>
1074     10082  0.0  0.0      0     0 pts/2    Z+   09:01   0:00 [kill] <defunct>

$ pstree 5577
winswitch_serve─┬─3*[kill]
                └─sh

[Antoine Martin]

You need to figure out why winswitch cannot access DISPLAY :61,
try running simple commands against that display:

DISPLAY=:61 xset q

Does this work?

If it does then something in the environment used by winswitch makes it fail.
If not, then you need to figure out why.

As I said, I suspect this is xauth related, so try:

xauth list

and

echo $XAUTHORITY

[Rogerio Bastos]

Replying to antoine:

You need to figure out why winswitch cannot access DISPLAY :61,
try running simple commands against that display:

DISPLAY=:61 xset q

Does this work?

Within NX session works, but withou (with NX running) don't

$ DISPLAY=:61 xset q
No protocol specified
xset:  unable to open display ":61"

[Antoine Martin]

can you show us:

echo $XAUTHORITY

in both cases?

[Rogerio Bastos]

In NX session:

$ echo $XAUTHORITY
/home/neptuno/rogeriobastos/.winswitch/server/sessions/61/xauth

Out:

$ echo $XAUTHORITY
<nothing>

[Antoine Martin]

Right, I had forgotten, winswitch defines a private xauth file for each NX session:

xmodmap_util.exec_xmodmap({'LANG': 'en_US.UTF-8', 'TERM': 'screen', 'SHELL': '/bin/bash', \
    'XAUTHORITY': '/home/neptuno/rogeriobastos/.winswitch/server/sessions/61/xauth', \
    'DISPLAY': ':61', 'PWD': '/home.....

So you need to point xauth there to access that display from outside the session, ie:

XAUTHORITY="/home/neptuno/rogeriobastos/.winswitch/server/sessions/61/xauth" xset q

This was not used when it tried to load the current default xmodmap (before applying your custom one), so the error followed just after "default xmodmap data not found, querying it (..) "

This is fixed in r4948.

---

Then I also found some other bugs with the session status callbacks, all should be fixed as of r4956.

However, from your logs I see that the xmodmap *is* being applied for your user:

xmodmap_util.exec_xmodmap({..},/home/neptuno/rogeriobastos/.winswitch/server/xmodmap/55aa08566aa8a64206bbf81b2dedcbf9d3.keys) \
    exec(['/usr/bin/xmodmap', '/home/neptuno/rogeriobastos/.winswitch/server/xmodmap/55aa066aa8a64206bbf81b2dedcbf9d3.keys'])=(,)

So there may well be something else going wrong.
Can you tell us a little more about your setup? Distro, etc. Is NFS involved?

Can you compare this file: /home/neptuno/rogeriobastos/.winswitch/server/xmodmap/55aa08566aa8a64206bbf81b2dedcbf9d3.keys with xmodmap -pke from the client machine?
Can you also post the output of: setxkbmap -layout us -variant alt-intl -print

Basically, winswitch grabs your client keymap by doing xmodmap -pke and xmodmap -pm, when you connect to the session it tries to apply those same keymaps but maybe we need a call to setxkbmap prior to that. That's what we do with xpra...

[Antoine Martin]

Also, please post from your client machine, the output of:

• setxkbmap -print
• setxkbmap -query

[Rogerio Bastos]

Replying to antoine:

Right, I had forgotten, winswitch defines a private xauth file for each NX session:

xmodmap_util.exec_xmodmap({'LANG': 'en_US.UTF-8', 'TERM': 'screen', 'SHELL': '/bin/bash', \
    'XAUTHORITY': '/home/neptuno/rogeriobastos/.winswitch/server/sessions/61/xauth', \
    'DISPLAY': ':61', 'PWD': '/home.....

So you need to point xauth there to access that display from outside the session, ie:

XAUTHORITY="/home/neptuno/rogeriobastos/.winswitch/server/sessions/61/xauth" xset q

This was not used when it tried to load the current default xmodmap (before applying your custom one), so the error followed just after "default xmodmap data not found, querying it (..) "

This is fixed in r4948.

The follow command works fine!

XAUTHORITY="/home/neptuno/rogeriobastos/.winswitch/server/sessions/61/xauth" DISPLAY=:61 xset q

[Rogerio Bastos]

Replying to antoine:

Then I also found some other bugs with the session status callbacks, all should be fixed as of r4956.

I upgrade client and server to version 0.12.15 and now keyboard is not set even in first connection.

However, from your logs I see that the xmodmap *is* being applied for your user:

xmodmap_util.exec_xmodmap({..},/home/neptuno/rogeriobastos/.winswitch/server/xmodmap/55aa08566aa8a64206bbf81b2dedcbf9d3.keys) \
    exec(['/usr/bin/xmodmap', '/home/neptuno/rogeriobastos/.winswitch/server/xmodmap/55aa066aa8a64206bbf81b2dedcbf9d3.keys'])=(,)

So there may well be something else going wrong.
Can you tell us a little more about your setup? Distro, etc. Is NFS involved?

I'm using Debian Wheezy (testing). My homedir was on NFSv4, but now is local and there was not change.

Can you compare this file: /home/neptuno/rogeriobastos/.winswitch/server/xmodmap/55aa08566aa8a64206bbf81b2dedcbf9d3.keys with xmodmap -pke from the client machine?

They are identical.

Can you also post the output of: setxkbmap -layout us -variant alt-intl -print

xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us(alt-intl)+inet(evdev)+group(shift_caps_toggle)+level3(ralt_switch)+compose(rctrl)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

[Rogerio Bastos]

Replying to antoine:

Also, please post from your client machine, the output of:

• setxkbmap -print

On the client:

$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us(alt-intl)+inet(evdev)+group(shift_caps_toggle)+level3(ralt_switch)+compose(rctrl)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

On the server:

$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "xfree86+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(pc105)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

• setxkbmap -query

On the client:

$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     us
variant:    alt-intl
options:    lv3:ralt_switch,compose:rctrl,grp:shift_caps_toggle

On the server:

rogeriobastos@stommel:~$ setxkbmap -query
rules:      xfree86
model:      pc105
layout:     us

[Antoine Martin]

• fix for kill in r5023 (use python native kill call)
• fix for keyboard mappings in r5024: just switch to use 'evdev' and let NX do everything (seems to work?) - may need to revert? (much platform testing needed)
• related: r5025 exposes the client layout and variant to the server (which we may need)

---

Please try to build from trunk or the beta packages just uploaded here:​beta:wheezy

Note: if needed, please remove the "keyboard" option from .winswitch/server/protocols/nx.conf

[Rogerio Bastos]

Hi,

I make some test com winswitch 0.12.16, apparently the keyboard mapping problem was fixed (I would like make another tests), but I can not suspend/resume sessions because process (including windows manager) are killed on the server-side.

Take a look in client​ and server​ logs.

Note: I need to downgrade to version 0.12.15 because this make winswitch unusable.

[Antoine Martin]

I see nothing wrong in the logs, it looks like the connection is made, as seen by the client:

[II] 2012/10/09 14:51:44 NXClientUtil.handle_line_log(ClientSession(:60 - nx - connecting),\
    Info: Established X server connection.) ServerConfig(stommel:83524822432)

And by the server:

[II] 2012/10/09 14:52:37 NXServerUtil.process_log_data(ServerSession(:60 - nx - connecting),16 lines) \
    setting new status=connected from line=Session: Session started at 'Mon Sep 10 14:52:36 2012'.\n

Then the next relevant thing that happens at either end is this (server) - very shortly after:

[II] 2012/10/09 14:53:15 NXServerUtil.process_log_data(ServerSession(:60 - nx - connected),2 lines) \
    setting new status=suspending from line=Session: Suspending session at 'Mon Sep 10 14:53:14 2012'.\n

Which means that nxagent decided to suspend (generally after receiving a SIGHUP signal), did you trigger that so soon after the session got connected? how? I see no request being made by the client (or the server).

Note: if you do suspend very shortly after starting a session, you may be able to trigger a race condition.

---

Please specify which debian packages you are using, as there are no official debian packages for nxagent/nxproxy. (download location, md5, etc)
The version I am using here works just fine, so I won't be able to fix anything unless I can reproduce this bug with the exact same setup.

---

Other things that could help me diagnose your problem:

• running the server in debug mode (either --debug-mode or via its config file) and posting the extract of the log of when the problem occurs
• posting the session files after the session has been closed (requires --no-delete-session-files as per session-debugging)

---

Note: looks like your client and server time is slightly out of sync, you probably should run ntp.

[Antoine Martin]

Never mind, fixed in r5058

Will push another minor update with the fix.

[Rogerio Bastos]

Still do not work, I can not open a NX session. This is from the client log:

[II] 2012/11/09 20:45:24 SimpleLineProcess.start() process(['/usr/bin/nxproxy', '-S', 'options=/home/rogeriobastos/.winswitch/client/sessions/f4bafdeebc6540c78700d94111ca3915/nx_options.txt:60'])=<Process pid=14464 status=-1>
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived(Loop: PANIC! Parse error at )
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived(environment)
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived( option ')
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived(us,port)
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived('.\n)
[DD] 2012/11/09 20:45:24 NXClientUtil.handle_line(ServerConfig(stommel:83524822432),ClientSession(:60 - nx - connecting),Loop: PANIC! Parse error at environment option 'us,port'.)
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived(Error)
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived(: Parse error at )
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived(environment)
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived( option ')
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived(us,port)
[DD] 2012/11/09 20:45:24 SimpleLineProcess.dataReceived('.\n)
[DD] 2012/11/09 20:45:24 NXClientUtil.handle_line(ServerConfig(stommel:83524822432),ClientSession(:60 - nx - connecting),Error: Parse error at environment option 'us,port'.)
[DD] 2012/11/09 20:45:24 SimpleLineProcess.childConnectionLost(0)
[DD] 2012/11/09 20:45:24 SimpleLineProcess.childConnectionLost(1)
[DD] 2012/11/09 20:45:24 SimpleLineProcess.childConnectionLost(2)

[Antoine Martin]

This was caused by your detected keyboard layout ("br,us"):

[II] 2012/11/09 20:45:24 NXClientUtil.get_nxproxy_options(ClientSession(:60 - nx - connecting),127.0.0.1,12460,1000000)=\
  {'product': 'WindowSwitch', 'media': 0, 'cleanup': 0, 'cookie': '2522532065d94859a1dd55106b196971', \
  'connect': '127.0.0.1', 'keyboard': 'evdev/br,us', 'port': '12460'}

Although this is a legitimate value for X11, NX barfs on it.
This is fixed in r5061 - will push another update soon.. sigh