Bug 1084798 - no protocol specified Error: Can't open display:
no protocol specified Error: Can't open display:
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: KDE Workspace (Plasma)
Current
x86-64 SUSE Other
: P5 - None : Normal (vote)
: ---
Assigned To: Fabian Vogt
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-11 07:13 UTC by filippos Filippos
Modified: 2019-03-27 18:48 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
terminal (9.41 KB, image/png)
2018-03-11 07:13 UTC, filippos Filippos
Details

Note You need to log in before you can comment on or make changes to this bug.
Description filippos Filippos 2018-03-11 07:13:12 UTC
Created attachment 763314 [details]
terminal

Hi my system is updated on a daily basis. 

When I start X and work everything is okay, but after some time I cannot execute X programs through terminal!
I get the following error.

Code:
$ xclock
No protocol specified
No protocol specified
Error: Can't open display: :0

DISPLAY=:0 or localhost:0 doesn't work
Setting XAUTHORITY doesn't work, too.

I also cannot execute from other X opened programs like okular or kate or kwrite though Firefox or Dolphin

The error from Dolphin is: KDEInit could not launch '/usr/bin/kwrite'

It's like loosing authentication ...

Only when I log off/on, everything is fine again! If I reboot the error restarts.



See more: https://forums.opensuse.org/showthread.php/530061-No-protocol-specified-Error-Can-t-open-display
Comment 1 Michal Srb 2018-03-12 08:34:59 UTC
Do you use vncserver by any chance? (There is existing issue where xauth started by vncserver overwrites existing Xauthority entries.)

When the issue happens, please collect and attach the output of following commands:
* echo $DISPLAY
* echo $XAUTHORITY
* echo $XAUTHLOCALHOSTNAME
* hostname
* xauth list

Note that the advice about "video" group from the forum is wrong. This is about authentication between X application and X server, "video" group has nothing to do with it.
Comment 2 filippos Filippos 2018-03-12 13:18:57 UTC
(In reply to Michal Srb from comment #1)
> Do you use vncserver by any chance? (There is existing issue where xauth
> started by vncserver overwrites existing Xauthority entries.)
> 
> When the issue happens, please collect and attach the output of following
> commands:
> * echo $DISPLAY
> * echo $XAUTHORITY
> * echo $XAUTHLOCALHOSTNAME
> * hostname
> * xauth list
> 
> Note that the advice about "video" group from the forum is wrong. This is
> about authentication between X application and X server, "video" group has
> nothing to do with it.


filippos@FOSTW:~/tmp> echo $DISPLAY
:0
filippos@FOSTW:~/tmp> echo $XAUTHORITY
/tmp/xauth-1000-_0
filippos@FOSTW:~/tmp> echo $XAUTHLOCALHOSTNAME
FOSTW
filippos@FOSTW:~/tmp> xauth list
FOSTW/unix:0  MIT-MAGIC-COOKIE-1  581b477914a05dc6ab34e9585e31d12c
filippos@FOSTW:~/tmp> xauth list
xauth:  file /tmp/xauth-1000-_0 does not exist
filippos@FOSTW:~/tmp> echo $DISPLAY
:0
filippos@FOSTW:~/tmp> echo $XAUTHORITY
/tmp/xauth-1000-_0
filippos@FOSTW:~/tmp> echo $XAUTHLOCALHOSTNAME
FOSTW
Comment 3 Michal Srb 2018-03-12 13:49:38 UTC
(In reply to filippos Filippos from comment #2)
> filippos@FOSTW:~/tmp> echo $XAUTHORITY
> /tmp/xauth-1000-_0

That is unusual place for xauthority file.

> filippos@FOSTW:~/tmp> xauth list
> xauth:  file /tmp/xauth-1000-_0 does not exist

Looks like something deleted it meanwhile. Maybe something is cleaning your /tmp/ regularly. Or whatever created it incorrectly determined that it is no longer needed.

Which display manager are you using? You can find out using this command:
update-alternatives --display default-displaymanager
Comment 4 filippos Filippos 2018-03-12 14:04:31 UTC
default-displaymanager - auto mode
  link best version is /usr/lib/X11/displaymanagers/sddm
  link currently points to /usr/lib/X11/displaymanagers/sddm
  link default-displaymanager is /usr/lib/X11/displaymanagers/default-displaymanager
/usr/lib/X11/displaymanagers/console - priority 5
/usr/lib/X11/displaymanagers/kdm - priority 15
/usr/lib/X11/displaymanagers/sddm - priority 25
/usr/lib/X11/displaymanagers/xdm - priority 10
Comment 5 Michal Srb 2018-03-12 14:16:41 UTC
Fabian, any idea why would sddm place XAUTHORITY file into /tmp/xauth-1000-_0? Thanks!
Comment 6 Fabian Vogt 2018-03-12 14:45:53 UTC
(In reply to Michal Srb from comment #5)
> Fabian, any idea why would sddm place XAUTHORITY file into
> /tmp/xauth-1000-_0? Thanks!

It doesn't - except if explicitly configured to.

I just did a search on github for that path and found https://github.com/KDE/kinit/blob/c9688c804d0d76f06062d2b8ab6bd06877510ea0/src/kdeinit/kinit.cpp#L1470

Which seems to be a bad workaround for a bug...

kinit (kdeinit5 actually) is the program which spawns various daemons like kded5 and klauncher.

The comment in the code seems to be wrong, as as long as the X server is running, there can't be any outdated cookies AFAICT.
Comment 7 filippos Filippos 2018-03-14 11:47:30 UTC
In .profile I've changed XAUTHORITY to .Xauthority and everything is okay now.
Thanks!
Comment 8 Fabian Vogt 2018-03-14 11:56:19 UTC
(In reply to filippos Filippos from comment #7)
> In .profile I've changed XAUTHORITY to .Xauthority and everything is okay
> now.
> Thanks!

Don't do that, it'll break everything once the fix for this arrives.

I made a patch to disable the broken behaviour of kinit for now, but it's not a real solution.
Comment 11 Stefan Dirsch 2019-03-27 16:51:32 UTC
Apparently this has been a kinit issue. Reassigning to Fabian.
Comment 12 Fabian Vogt 2019-03-27 18:48:32 UTC
(In reply to Stefan Dirsch from comment #11)
> Apparently this has been a kinit issue. Reassigning to Fabian.

Yup - it's fixed meanwhile.