[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

systemd: time-outs, journal size, Xorg terminals

I prefer SysVinit to Systemd, in the same way I prefer OSS to ALSA, and ALSA to PulseAudio: the newer stuff creates problems where there were none. Among these problems are locating configuration commands or files in the face of opaque memory or CPU hogging defaults.

time-outs

During shut down and start-up, systemd will wait too long to kill or initialize internet connections, among other things. Set the systemd time-out restrictions...

dhcpcd tries to initialize

After an update, dhcpcd occasionally is re-enabled at boot. Since it tries all interfaces, it will hang on any that are not connected. Furthermore, the process is partly obscured, so it's tricky to find. The standard "list-unit-files" does not give a complete syntax. So although one disables dhcpcd.service, the other service is not fully named and is cryptically called by a different name in boot.

# systemctl list-unit-files |grep dhcpcd
dhcpcd.service disabled disabled
dhcpcd@.service indirect disabled

$ systemctl status dhcpcd*@*.service
* dhcpcd@enp4s0.service - dhcpcd on enp4s0
Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2020-06-09 04:32:17 PDT; 7min ago
Process: 362 ExecStart=/usr/bin/dhcpcd -q -w enp4s0 (code=exited, status=1/FAILURE)

The name you need here is dhcpcd@enp4s0.service, it cannot be disabled as the first name given, simply dhcpcd@.service. To stop this hang...

# systemctl disable dhcpcd@enp4s0.service
Removed /etc/systemd/system/multi-user.target.wants/dhcpcd@enp4s0.service.

journald logs

Prior to systemd, boot-ups used to log to /var/log, pretty much auto-magically via rsyslog (syslog). The only thing one had to configure was chron's timeline for rotating old logs into the trash. Suckily, journald logs grow until they take over something like 10% of disk space by default. To me, it's yet another mistake of the last 8 years of Linux -- adding boggy new application layers instead of improving and simplifying long-standing daemons¹. At any rate, journald must be configured if you want anything reasonable and intelligible. Secondly, you must use "journalctl" the read them, because they are stored in a binary format.

Since there are about 30 settings in /etc/systemd/journald.conf, an hour is wasted researching journald's settings.

# nano /etc/systemd/journald.conf
Storage=auto
SystemMaxUse=200K

When I want an ASCII record for grepping, etc, I use journalctl -r -o short-iso ("r" reverses time to put most recent on top, "short-iso" is for giving normal clock timestamps), and save screen output to text:

$ journalctl -r -o short-iso 2>&1 file.txt

Alternatively, one can output other formats such as the apparently standard JSON format. It cannot however export directly to text unless it's to another application.

This the file when the system is running well and no logging is needed:

Storage=none

notes

• 200K of logging seems to cover about the last 10 boots.
• journalctl --verify checks logs for corruption

xorg terminals

If systemd is not restricted, it will open 40+ terminals when you open X, buring hundreds of unnecessary MB's of memory. Seven terminals is sufficient for operations inside X

# nano /etc/systemd/logind.conf
NAutoVTs=6

---

¹It's as stupid as when PulseAudio took hold of Alsa (which itself overlaid OSS)

xorg odds and ends, xorg.conf

xterm settings

In Arch it's become slightly difficult to implement xterm settings. The way Xorg initializes has changed -- it no longer directly loads .Xdefaults or .Xresources. Instead, they are called by .xinitrc. Sometimes, this extra step fails and your xterm will look vanilla. The correct .xinitrc lines calling .Xresources should already be present, and should look something like...

$ nano .xinitrc
if [ -f "$userresources" ]; then

xrdb -merge "$userresources"

fi

Troubleshoot: save either .Xresources or .Xdefaults. I kept .Xresources and therefore deleted .Xdefaults, but I could have switched this. Add your xterm customizations to whichever of the two is kept. Check these customizations by loading the file directly...

$ xrdb .Xresources

...then open a new xterm to see if it looks configured. I typically make modifications of color, clipboard availability, and so forth, eg...

$ nano .Xresources
XTerm*selectToClipboard:true

... but this can also be added to one's command to open xterm in their icewm menu.

If xterm was modified, .Xresources is being called by .xinitrc. However if xterm looks unmodified, then either .xinitrc needs modification to properly call .Xresources or, .Xresources requires further work.

xorg install order

1. # pacman xf86-video-ati There are several drivers to pick from; you'll need the correct one for your chip. I found my chip this way:

   $ lspci |grep vga
   VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780MC [Mobility Radeon HD 3100]
   

   So I had the Radeon HD 3100 RS780MC chip, which corresponded with the xf86-video-ati driver. Since it's radeon, I also proceeded with the next step; others may not need it

2. # nano /etc/mkinitcpio.conf
     MODULES="radeon"
   # mkinitcpio -p linux
   # reboot

3. # pacman xorg-xinit xorg-server xorg-server-utils xorg-apps (80Mb)
4. # pacman icewm icewm-themes (20Mb) just get some WM in there to test all the settings
5. # pacman dillo a light browser for looking stuff up about the install
6. get the skeletons for /etc/X11/xinit/xinitrc, /usr/share/icewm (the entire directory, then chown it and change it to ".icewm"), and /etc/dillo/dillorc
7. modify ~/.xinitrc to add "exec icewm"
8. I like to reboot here, before starting X, but some might just logout and log back in. Either way, "startx", and then tweak and add apps

xorg.conf

x configuration is a persisting mystery. The following may help in Arch.

1. the files to configure 90% of your X session are in /etc/X11/xorg.conf.d/ directory
2. create /etc/X11/xorg.conf.d/10-extras.conf for your custom stuff, like screen blanking, Blender mouse remapping, and so on -- all in one file
3. the config files can have multiple "ServerLayout", "InputDevice", etc. sections
4. comments in configuration files in the directory are with pound sign "#"
5. .xinitrc and .Xresources play about a 10% role
6. /etc/profile.d/locale.sh is important for "locales", which affect font encoding. You want all of these to be "C"

boot crashes, x crashes, video crashes, mouse crashes, kernel panics

A friend has an old (c.2011) HP box that was running Arch.

boot hang

Endless possibilities. Here are some ways I've seen it solved

• Solution: # systemctl disable dhcpcd.service. Symptoms: Boot hang with thousands of lines of fails including cgroup fails with appearance the OS or systemd are corrupt. Real source: dhcpcd.service attempts to autoconnect at startup. If it times out, eg, there's no ethernet cable, systemd interprets this nuisance as a fatal f*cking error. Nevertheless it continues to run its boot script, failing every subsequent step, and generating thousands of lines of spurious errors. Time: an entire Saturday, until lucked into it around line 1500 of an arch-chrooted (from USB) journalctl -r.

x crash

Buddy was uses Wikimapia and Google Maps in two open browser tabs. He thought "these are just websites, why does my system keep locking up", but of course he had selected perhaps the two most polygon intensive sites on the Web about which to make such a claim, and he was moving his mouse at video game speeds. All this on a 2011 HP with onboard G31 chip graphics. Little wonder the persistent failures, mostly of two varieties: 1) lockups, and 2) exit to terminal with kernel panics. Some possibilities:

1. xorg setting for video card
2. xorg setting for mouse
3. browser leaks with multiple many-polygon pages open (maps)
4. the old Intel 82G33/G31 integrated controller card being overwhelmed
5. ?

logs

We're looking for two main log types: Xorg crashes, and Kernel crashes. Xorg is the easiest -- hasn't changed much over the years. We can still find Xorg logs in /var/log/Xorg.0.log.old and copy to our user directory to read them in any text editor. Failures stand out, and there is usually enough information to start modifying one's xorg.conf file to fix whatever's wrong. In the case of my friend, it appears there was nothing failing and writing to Xorg.log, at least on a first-look.

Kernel crashes. During crashes, writing can be inconsistent; we can't be certain we'll have information. Additionally, journald crash logs are written in binary and, further, compressed, and so require the journalctl client to read whatever's in there (and of course "whatever's in there" can become corrupted during a panic). So it's 50-50 if we can see anything in these logs. IMO, verifying a corruption-free log is the place to begin.

# journalctl --verify

...in the case of my friend's logs, this revealed a plethora of corruptions at times I could not decipher, but may have corresponded to the panics.

Given all of this, it appeared the best thing to do was get some text readable log information.

# nano /etc/systemd/journald.conf
Storage=none
ForwardToSyslog=yes

...next crash, I should be able to see if there's anything out there in human readable text. Meanwhile...

# journalctl -b

... and look for errata.

video card

On the video card front, his old Intel 82G33/G31 is onboard and shares memory (fatal), but also appears to have some VRAM. No GPU.

[solved] xbacklight -- try to adjust your backlight to preserve it

I recently had an LCD display burn-out its backlight element and had the following consideration:

• $60 (1.5 hrs) Replace screen and backlight combo
• $12 (5 hrs) Replace backlight only

On my current schedule,I did the $60 but, since I was doing it for the backlight, I wanted to be sure I adjusted the backlight to a low setting going forward. The commands I'm aware of are

• xgamma
• xbacklight
• xrandr

I've regularly used xgamma and xrandr in the past, but was never sure what I was adjusting -- the lcd, the backlight, or some blend. For example, with the new display, even when I set the gamma very low, eg

$ xgamma -gamma 0.1

...I would see what appeared to be a full-intensity backlight combined with a low contrast LCD setting. A similar problem appeared if I used xrandr, eg

$ xrandr --output LVDS --brightness 0.2

... which would give a bright haze (the backlight?) overlaying a barely visible display underneath. I wanted to definitively adjust the backlight so I could begin to untangle what was what. "Xbacklight" seemed the most logical choice. Murphy arrived immediately.

xbacklight problem

$ xbacklight
No outputs have backlight property

Checking the arch wiki on backlight control, we get the mysterious information:

All methods are exposed to the user through /sys/class/backlight and xrandr/xbacklight can choose one method to control brightness. It is still not very clear which one xbacklight prefers by default.

There is a note about how to fix the error message if one is using Debian, but of course Arch is not Debian. I did find the following directory however:

/sys/class/backlight/acpi_video0/

Based on what I read here from greengeek, I did the following with a nice dimming effect (required root)

# echo 1 > /sys/class/backlight/acpi_video0/brightness

Echoing a value obviously doesn't use an application (eg., xbacklight), but it appears to set the backlight effectively, and uses settings between 0 and 2.

final command combination

With the new LCD and backlight, a crisp setting appears to be

$ xgamma -gamma 0.4
# echo 0 > /sys/class/backlight/acpi_video0/brightness

xrandr and external displays or projectors

A person can get a printout of possible display settings for an external device attached to their desktop or laptop by simply typing $ xrandr. Using these, a person can set exact refresh settings for secondary displays, however, I haven't found backlight control of these displays. Still, xrandr is great to simply turn the display/projector on and off (with the proper screen resolution). Note the screen resolution of your laptop (eg. 1200x800)and send it to a projector...

$ xrandr --output VGA-0 --mode "1280x800" [initiates external video]
$ xrandr --output VGA-0 --off [terminates external video]

If I don't put the quotation marks around 1280x800, xrandr will bark at me that the resolution isn't found (most projectors don't natively have it).