Does turning daemon on cause the socket errors?
Yes, at least turning daemon off makes the socket errors disappear.
(please include the exact command line used)
I'm confused: your original post stated that you were getting those
socket errors when not using the socket option.
What has changed?
Doing "/usr/bin/xpra --socket-dir=/tmp start :10" or "/usr/bin/xpra
start :10" produces the same error in the log file. So socket-dir does
not make a difference. (This was your first suggestion)
You didn't answer the question about $HOME being on nfs or something else.
This would help me reproduce the problem.
As far as I know, no. However the setup of this machine has not been
done by me.
I've added some logging on my side. In server_core.py in init_sockets
line 235 I added:
log("socket name '%s'", sock.getsockname())
when I run with "/usr/bin/xpra --daemon=no start :10 -d all" I receive
this line in my logs:
2015-06-22 20:27:01,413 socket name '/tmp/hostname-10'
When I run in daemon mode with "/usr/bin/xpra start :10 -d all" I get
this in my log file
2015-06-22 20:26:36,346 socket name ''
I hope I'm being a bit more clear now.
Ronald
On 22/06/15 18:58, Antoine Martin wrote:
On 22/06/15 17:57, Ronald Sterckx wrote:
"/usr/bin/xpra --daemon=no start :10" seems to work though
I'll rephrase that. This does work, I can connect in this case. The
log is
(snip)
This does not complain about the socket as it normally does. This is
not really a workable solution though.
Why is it not workable?
Does turning daemon on cause the socket errors?
When I use socket-dir the log file still states:
(please include the exact command line used)
I'm confused: your original post stated that you were getting those
socket errors when not using the socket option.
What has changed?
2015-06-22 17:43:06,230 usually, only a single pulseaudio instance
can be running for each user account, and one may be running already
Traceback (most recent call last):
File
"/usr/lib/python2.7/dist-packages/xpra/server/gtk_server_base.py",
line 61, in add_listen_socket
sock.listen(5)
File "/usr/lib/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 22] Invalid argument
2015-06-22 17:43:06,230 xpra is ready.
2015-06-22 17:43:06,287 video encoder 'nvenc4' could not be loaded:
2015-06-22 17:43:06,288 No module named pycuda
This does complain about the socket and I can't connect.
You didn't answer the question about $HOME being on nfs or something else.
This would help me reproduce the problem.
Cheers
Antoine
Ronald
On 22/06/15 17:11, Antoine Martin wrote:
On 22/06/15 15:19, Ronald Sterckx wrote:
Hi,
I have Ubuntu vivid. My desktop is connected to an Active Directory,
which might be related.
Possible, I can't imagine why unless you use system authentication
(auth=sys).
I have tried "--socket-dir=/tmp" but that didn't help.
FYI: You need to use this option for both the server and clients.
"/usr/bin/xpra --daemon=no start :10" seems to work though
Seems to?
Does "xpra info" work? (specifying socket-dir if appropriate)
Cheers
Antoine
Ronald
On 12/06/15 14:26, Antoine Martin wrote:
On 12/06/15 09:08, Ronald Sterckx wrote:
Hi,
I try to start xpra on display 10 by issuing
$ xpra start :10
Entering daemon mode; any further errors will be reported to:
/home/INTRA/ronalds/.xpra/:10.log
(snip)
Traceback (most recent call last):
File
"/usr/lib/python2.7/dist-packages/xpra/server/gtk_server_base.py",
line 61, in add_listen_socket
sock.listen(5)
File "/usr/lib/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 22] Invalid argument
That's a very odd looking error you've got there.
I am unable to reproduce this on Ubuntu Vivid, or any other distro for
that matter.
Is your home directory on NFS or something?
If that's the case, you should be using the "--socket-dir=DIR"
option to
place the xpra sockets outside $HOME.
Cheers
Antoine
_______________________________________________
shifter-users mailing list
[email protected]
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
[email protected]
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
[email protected]
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
[email protected]
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
[email protected]
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
[email protected]
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
