Sorry, the strace part was from memory and plain wrong...
xmove tries, and fails, to read from some (arbitrarily numbered)
filedescriptor, repeatedly...
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7
setsockopt(7, SOL_SOCKET, SO_REUSEADDR, NULL, 0) = -1 EINVAL (Invalid argument)
setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
connect(7, {sa_family=AF_INET, sin_port=htons(6001), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
ioctl(7, FIOCLEX) = 0
ioctl(7, FIONBIO, [1]) = 0
write(7, "l\0\375\0\0\0\0\0\0\0\v\0", 12) = 12
read(7, 0xafcc0d5b, 8) = -1 EAGAIN (Resource temporarily unavailable)
read(7, 0xafcc0d5b, 8) = -1 EAGAIN (Resource temporarily unavailable)
(and a few thousand more of those failed reads)
Looks like it tries to open a tcp connection to port 6001 on
localhost, while the X server is configured *not* to accept tcp
connections. This can't work...
What puzzles me is that the connect works, although it's tcp... there
is nothing listening on that port, and it's unfiltered (so no silent
dropping of packages or anything). But I'm not familiar with those
socket options above that and one of the setsockopt calls even failed...
Is there a way to make xmove use unix domain sockets? Before you
laugh, this should make moving x clients over forwarded ssh
connections possible, *without* opening the xserver to tcp connections
from outside.
Alternatively, I could try to have the xserver listen on 127.0.0.1...
Kind regards
FDF
--
Friedrich Delgado Friedrichs <friedel@nomaden.org>
Attachment:
signature.asc
Description: Digital signature