You are not logged in.
Hi,
i have a strange issue with my installation:
after logging in everything works as expected. After some time (not the same amount each time) X stops responding to requests. But every application that is open at that point will respond normaly until it tries to open a new window or such things. xrandr returns "protocol not specified Error: cannot open display: :0.0" like in this post https://bbs.archlinux.org/viewtopic.php?id=109914
But because i can use the system like normal X seems to be working fine.
After some more time the session will suddenly stop. journalctl shows some daemon that quits because of a not responding X resulting in closing the session.
If that might be relevant:
lightdm as DM
xfce4 as DE
NFSv4 for Homes
Kerberos for Auth
LDAP for NSS
I have not idea what results in a not responding X
Hope there will be a solution.
Sincerely,
Daniel
Last edited by dlaube (2018-08-30 13:30:34)
Offline
Output of "hostnamectl"?
Offline
Static hostname: 01.c1.rgp
Icon name: computer-desktop
Chassis: desktop
Machine ID: 18bf7ef9044b41569295251bb120eb5a
Boot ID: 9b8f4dba3de44d12a90c9524182c632c
Operating System: Arch Linux
Kernel: Linux 4.14.67-1-lts
Architecture: x86-64Offline
No, that's not it (and I see you had been there ;-)
However, a changing hostname is still the common cause, so check whether it changes for other reasons.
Also check your dmesg, journal and Xorg log - something would close the X11 socket?
For the records: this is a local connection and you're not listening on tcp connections?
Offline
X is not listening on tcp, just on unix socket as far as i can tell.
Noteworthy: lightdm starts an X for each user. When using the same X server for lightdm and session using the xserver-share configuration option the issue seems to be gone (running for about 1h now).
Offline
Update: issue resolved by masking systemd-tmpfiles-clean
It seems like systemd-tmpfiles-clean removes some files which are required for X communication.
Offline
Yes, the socket in /tmp/.X11-unix - most likely.
The question is "why".
The service kicks in after local-fs.target & time-sync.target - the prime contender here to delay things is the time-sync.target. Checked your journal?
Also you should not have to mask it? It's disabled by default and pretty useless (on a brief look, all files in the config should be on tmpfs, thus nuked w/ a reboot anyway)
Offline
that makes sense.
It was enabled by a timer. I did not check the configuration of the timer though. Running the command from systemd-tmpfiles-clean manually forces the issue to appear.
Offline