Bug 359185

Summary:	screensaver failing if changing hostname
Product:	[Unmaintained] kscreenlocker	Reporter:	Georg Schlisio <g.schlisio>
Component:	greeter	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	bshah, kde, mgraesslin, plasma-bugs-null, sowieso
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Georg Schlisio 2016-02-09 14:12:28 UTC

If changing the hostname via
[code]
$ hostname
example
$ hostname badexample
[/code]
and locking kde5 plasma session afterwards, kscreensaver complains about being malfunctioning. it recommends switching to a console and executing 'loginctl unlock-sessions' to access the screen again.
changing hostname back to the value it was before plasma started fixes the problem.

Reproducible: Always

Steps to Reproduce:
1. start plasma
2. change hostname
3. lock screen

Actual Results:  
error warning

Comment 1 Martin Flöser 2016-02-09 15:02:27 UTC

can you try the binary kscreenlocker_greet with --testing after having changed the hostname? It's in the libexec path.

Comment 2 Georg Schlisio 2016-02-09 15:31:17 UTC

well
~ > /usr/lib/kscreenlocker_greet --testing
No protocol specified
QXcbConnection: Could not connect to display :0
[1]    2509 abort (core dumped)  /usr/lib/kscreenlocker_greet --testing

this happens with a lot of programmes, only a restart of plasma fixes this.

Comment 3 Georg Schlisio 2016-02-09 15:32:20 UTC

no, sorry, a reset of the hostname fixes this as well.

Comment 4 sowieso 2016-02-09 15:53:00 UTC

I can confirm this behaviour on another Archlinux system (intel drivers).

Comment 5 Martin Flöser 2016-02-09 16:01:42 UTC

I think the problem is that X11 has problems with the hostname change.

Comment 6 Georg Schlisio 2016-02-09 16:28:37 UTC

looks like you are right:
~/.Xauthority contains the session cookie to authenticate to the xserver, and it contains the hostname. the same holds for /tmp/xauth-${UID}-0 .
updating hostname in the latter seemingly fixes this (but produces errors not mitigated by updating the former file).
so, sorry for bugging you guys, but this is not related to kde.

Comment 7 Georg Schlisio 2016-02-09 19:41:20 UTC

this is not supposed to work, X cannot handle this.
however, one can generate a serverinterpreted family xauth entry with [code]xhost +si:localuser:`whoami`[/code].
there are still some warnings, but everything works as expected.

this might then be closed as INVALID, NOTABUG or similar.

Comment 8 Martin Flöser 2016-02-10 07:06:50 UTC

I remember that there was a watcher for hostname changes in regard to X. Just found a relevant mail thread: http://kde-core-devel.kde.narkive.com/hFmhuy2u/kdelibs-kded-disable-khostnamed-in-kded

It might give you some ideas what goes wrong. My understanding of the mail is that changing the host name should not affect X, because the distros ensure it. Maybe something broke.