<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
- fixed initial oversize mail, removed some company footers, sorry
- <br>
<div class="moz-cite-prefix">Op 27-02-13 18:32, Germ van Eck
schreef:<br>
</div>
<blockquote cite="mid:512E4344.1010306@stationtostation.nl"
type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Got it solved.<br>
<br>
germ@sts012:/var/opt/thinlinc/sessions/germ/1> xauth -v -f
Xauthority list<br>
Using authority file Xauthority<br>
sts012/unix:1 MIT-MAGIC-COOKIE-1
ce5f13a401d5cf973e42e7b12e1b37a2<br>
<br>
germ@sts012:/var/opt/thinlinc/sessions/germ/1> xauth -f
Xauthority add "$(hostname)/unix:1" MIT-MAGIC-COOKIE-1
ce5f13a401d5cf973e42e7b12e1b37a2<br>
germ@sts012:/var/opt/thinlinc/sessions/germ/1> gedit<br>
_IceTransSocketUNIXConnect: Cannot connect to non-local host
sts012<br>
_IceTransSocketUNIXConnect: Cannot connect to non-local host
sts012<br>
<br>
(gedit:29328): EggSMClient-WARNING **: Failed to connect to the
session manager: Could not open network socket<br>
<br>
<br>
The gedit command takes a long time, as it tries to connect to the
no longer existing hostname sts012 twice, but I now know it is
because of the hostname.<br>
<br>
I am pretty sure I fixed it for myself by changing my DHCP network
configuration, now you may decide if this is a bug in thinlinc or
not...<br>
<br>
<div class="moz-cite-prefix">Op 27-02-13 18:05, Germ van Eck
schreef:<br>
</div>
<blockquote cite="mid:512E3CEB.3050202@stationtostation.nl"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
Output of xdpyinfo, working (after logout/login): <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://pastebin.com/L0WXefdD">http://pastebin.com/L0WXefdD</a><br>
Strace of xdypyinfo, working (after logout/login): <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://pastebin.com/DZrEzYEB">http://pastebin.com/DZrEzYEB</a><br>
Strace of xdpyinfo, broken (before logout): <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://pastebin.com/kQbVYsaV">http://pastebin.com/kQbVYsaV</a><br>
<br>
I am trying to decipher the strace output, as I am not exactly
an expert in the internals of Xorg, this is hard. I think what
this is trying to do is read a "Magic Cookie" from
/var/opt/thinlinc/sessions/germ/1/Xauthority , and use it to
authenticate against Xorg.<br>
It seems to succeed in reading the cookie, but it then fails to
use it to authenticate somehow.<br>
<br>
If I read the xinit log, symlinked from ~/.thinlinc, I read:<br>
xauth: file /var/opt/thinlinc/sessions/germ/1/Xauthority does
not exist<br>
xauth: (argv):1: bad display name "sts012:1" in "add" command<br>
xauth: file /var/opt/thinlinc/sessions/germ/1/Xauthority does
not exist<br>
<br>
The maybe interesting part here is the hostname. I noticed our
DHCP server (MS Active Directory DHCP thing) giving me one of
four different hostnames. Can this be the cause?<br>
<br>
I could fix this by configuring the DHCP so that it ignores the
hostnames it receives by DHCP, but I think the thinlinc software
should also not break on it.<br>
<br>
<div class="moz-cite-prefix">Op 27-02-13 15:20, Peter Astrand
schreef:<br>
</div>
<blockquote
cite="mid:alpine.LRH.2.03.1302271513240.28974@cendio.se"
type="cite"> <br>
I see. Besides /tmp/.X11-unix/X1, you could verify that
$XAUTHORITY still points to the correct authority file, and
that it is readable. <br>
<br>
It could also be a problem with AppArmor. You could try to
disable it and see if that solves the problem. And of course,
you can also create a debug log by installing and running,
say, "strace xdpyinfo &>log". <br>
<br>
Regards, <br>
Peter <br>
<br>
<br>
<blockquote type="cite">/tmp/.X11-unix/X1 still exists
(created at my login time). I have read and <br>
investigated the bug you mentioned and I don't think I am
affected with it. <br>
I also don't really understand the problem they are trying
to solve with <br>
systemd-tmpfiles, but that is another topic.. <br>
Strange thing is I can create new windows for running
applications, I am now <br>
writing this mail in a new Thunderbird window. Also the
problem does not occur <br>
when I work directly on the system itself. <br>
<br>
I am running Suse 12.2, I was mistaken. It doesn't have a
systemd-tmpfiles <br>
package, but my systemd version is 44-10.8.1. The "44" is a
number assigned by <br>
Suse, and the 'upstream' version is 10.8.1, if I remember
RPM packaging <br>
correctly. <br>
<br>
Regards, <br>
Gerben <br>
<br>
</blockquote>
Op 27-02-13 14:00, Peter Astrand schreef: <br>
<br>
We haven't heard of this problem before. However, my
guess is that <br>
something removes /tmp/.X11-unix/Xn (where n is the
session number) <br>
after some time. As I understand it, OpenSuse 12.1 uses
"systemd", <br>
which is known to cause compatibility problems. I found
this bug <br>
report: <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=674194">https://bugzilla.redhat.com/show_bug.cgi?id=674194</a>
<br>
<br>
It seems that you need to use systemd-tmpfiles v18 or
later to avoid <br>
this problem. Or, use a Linux distribution without
"systemd" :-) <br>
<br>
Rgds, <br>
Peter <br>
<br>
On Wed, 27 Feb 2013, Germ van Eck wrote: <br>
<br>
For the last year, and after several
(re-)installations <br>
I keep having the issue that I can't start new X <br>
applications after some time. When I try to do
this from <br>
the terminal, I get the error "Cannot open
display". <br>
<br>
myusername@mypc:~/sbin> echo $DISPLAY <br>
:1.0 <br>
myusername@mypc:~/sbin> w <br>
13:18:14 up 8 days, 1:13, 3 users, load
average: <br>
0,77, 0,63, 0,60 <br>
USER TTY FROM LOGIN@ IDLE
<br>
JCPU PCPU WHAT <br>
myusername thinlinc :1 10:06
0.00s <br>
0.00s 0.00s tl-session: myusername <br>
myusername pts/1 :1.0 11:09
0.00s <br>
0.09s 0.00s w <br>
myusername@mypc:~/sbin> gedit <br>
No protocol specified <br>
Cannot open display: <br>
<br>
Both the client and server systems are running
Opensuse <br>
12.1. The server hardware is an Apple iMac (ATI
using <br>
binary driver), the client is a HP Laptop. <br>
<br>
I use Virtualbox with Win7. The
thinlinc-vnc-server <br>
version is 3.4.0-3513, X.Org is at 7.6_1-3.2.1. <br>
<br>
Both a fix and a workaround would be appreciated,
I now <br>
solve this by logging out/in, but this becomes
very <br>
annoying. <br>
<br>
</blockquote>
</blockquote>
</blockquote>
<div class="moz-signature">
<div class="WordSection1"><br>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Verdana","sans-serif""><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>