xmodmap: unable to open display ''

[robstr12]

Hello.  First, let me say that
5.9 Standard GOLD built on Dec-16-07 on Linux 2.6.22.14
Is one wicked cool distro, thanks!!!

I wish to report something:  When trying to scp a file to the box, I see this error:
xmodmap:  unable to open display ''

(I can scp files FROM my Vector box just fine, thank you, only not TO it). 

When I use the -v switch to scp, I do not see that error, as a matter of fact, I
see no errors at all, the exit status is 0, but yet the file is not on my Vector
box:

Code:

-bash-3.2$ scp -v testfile rlw@nocona:/home/rlw
Executing: program /usr/bin/ssh host nocona, user rlw, command scp -v -t /home/rlw
OpenSSH_4.6, OpenSSL 0.9.7j 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to nocona [192.168.1.110] port 22.
debug1: Connection established.
debug1: identity file /home/rlw/.ssh/identity type -1
debug1: identity file /home/rlw/.ssh/id_rsa type 1
debug1: identity file /home/rlw/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'nocona' is known and matches the RSA host key.
debug1: Found key in /home/rlw/.ssh/known_hosts:8
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/rlw/.ssh/identity
debug1: Offering public key: /home/rlw/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/rlw/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
rlw@nocona's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: scp -v -t /home/rlw
You are working as rlw
-bash-3.2$ debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

-bash-3.2$

Now, in an effort to get around this, I commented out the following line in my
~/.bashrc file:
#use custom keymap
xmodmap ~/.Xmodmap

So that it is now:
#use custom keymap
#xmodmap ~/.Xmodmap

And rebooted the machine.

Then, I no longer get the error
xmodmap:  unable to open display ''
but the file is still not transferred.

I know that at least one other user is having this error, from this post here:
http://www.vectorlinux.com/forum2/index.php?topic=4585.msg30148#msg30148

So, I don't think that 'scp' is failing because of xmodmap.  As a matter of fact, even with
xmodmap not sourcing ~/.Xmodmap, scp still returns an exit status of 0, which SHOULD
indicate success, but the scp is not successful (at least, I cannot see the file on the
Vector box).

Is anyone else having this issue?  Is there a fix known?




High Regards!

Robert

[Triarius Fidelis]

I have no idea what's wrong with scp, but try running it under X and see what happens.

[robstr12]

Thanks for your reply, hanumizzle.

It still failed.

Now, I am trying to scp from OpenBSD 4.1 (which is my gateway/firewall/router).  Perhaps that is the problem.  I have some other things to try.  I am going to forward a port tonight through that OpenBSD box so that I can try to scp a file to the Vector box from some other GNU/Linux box.  I will report what I find.

Oh, and the edit to ~/.bashrc took care of the xmodmap error, btw.   So, at this point, I'm only dealing with the failure of scp.  If I find out anything interesting I will post.

[jonface]

Edit 2: Just saw the other post on the fix. doh!

Although not the exact same error, I'm getting,

Code:

xhost:  unable to open display ""

VL 5.8 standard, 2.6.18.5.

I'm also getting exit status 0 with -v . Surely can't be the only ones with this problem?

Edit: tried with root as well, same problem.

[saulgoode]

SCP is easily confused by any text that is outputted during its non-interactive login. Unfortunately, the Vector default setup produces such output and you will need to modify two files to fix this problem. Fortunately, the kernel does not associate a tty with a non-interactive login; so the /usr/bin/tty command can differentiate between an interactive login and an SCP 'login'.

.bashrc is one of the files needing modification: you have to assure that nothing is output by this script when performing an SCP. Both xmodmap and xhost will generate output. You could redirect the output of the commands to /dev/null -- both error and stdout -- by appending '>/dev/null 2>&1' or you can make the execution of the commands conditional on there being a tty associated with the process by wrapping the command within an IF statement (assuming that the command is not needed for non-interactive logins, which I believe to be the case).

if  /usr/bin/tty >/dev/null; then
  xmodmap ~/.Xmodmap
fi

The other file which needs to be amended is /etc/profile.d/vasm.sh; and you will need root access to modify that file. vasm.sh produces quite a bit of output which you will have to wrap within an IF block just as above. For the version of Vector I have available the 'if /usr/bin/tty >/dev/null; then' would be placed directly after all of the color codes, and the 'fi' would be placed after the last line containing an 'echo' command (which precedes the line starting with 'PS1=').

You could probably solve the problem wrapping the entire script (both bashrc and vasm.sh) within an IF block and not create any problems. I have not tried this but it appears that all of the setup being performed is only of use during interactive logins.

Hopefully, future versions of Vector will contain corrected login scripts so this problem doesn't exist.