Friday, November 11, 2016

[solved] xinit: unable to connect to x server: Connection refused

This is a common, highly annoying, permission fail following any update. If your /etc/group and /etc/shadow files have customary arrangements, and you haven't created conflicting rules in /etc/udev/rules.d, then it's not your fault -- you did your normal user-level part. Defenestration of various programmers is the deserved solution because, since the advent of PAM, LDAP, NSS and the other ridiculous kludge of "security" since Sept 2001, which have mostly secured users out of their own systems, it's probably another feature requiring a permission adjustment. If so, you have days of work ahead. Try these below and don't get into security files unless these don't work.

If no programmers are handy to toss, here are some options
  1. Log out entirely, then log back into your user and make a second attempt
  2. Try rebooting entirely. If it's a large update, this solves it nearly every time.
  3. You have two main configuration files for X, besides the regular stuff in .xinitrc (or .xsession if you're a dumbass who uses a DM):
    • /etc/X11/xorg.conf -- you should never have to fuck with this file but (ironically, as with everything else in Linux) you will nevertheless have to do so one day after a "helpful" "update" (although your system was running just fine before these) at which point you will have no experience at doing so, since you never were supposed to have to edit it, but now you suddenly have to and... (you guessed it) at a level assuming you have have a CS degree and years and years of experience with that file. Tada!
    • /usr/share/X11/xorg.conf.d -- this is the bullshit directory where 2 million conflicting configuration files live, files you cannot easily do anything but printout and lay side by side on the living room floor (which you don't have since you lost your job coming in late after all-nighters attempting to fix permission problems added since 2001) and desperately hope that you can identify some conflict between them or the aforementioned /etc/X11/xorg.conf file before losing another weekend or relationship with these printouts lying all over the house. Fun, right?

solutions

Reboot after large updates when this happens.

$ strace startx 2>&1 |tee bigfile.txt
This is obviously much better than a log file. Look for X authorities and see if they're not forthcoming.

$ xauth
Is there an ~/.Xauthority file? Two problems are possible. One, it's not being created, or two, it's being created with no content. It's a binary file, typically about 49 bytes in size, when functional. Zero bytes is not good, so then try....

$ xauth list





2 comments:

Anonymous said...

Hi, I just want to say thank you for this. I spend ages trying to figure out by my start x doesn't work and only after reading this I realized my .Xauthority is completely empty.

Unknown said...

Hello, for me using another user different to root solve the issue.
Best regards,
Moustapha Kourouma