Solved Xorg "serverauth" file does not exist

Sevendogsbsd

Sevendogsbsd

So this has been posted before, but several years ago and I didn't want to necro-bump. I don't use a display manager, just use startx to start my window manager. Every time I start X, I get the error message saying "/home/myuser/.serverauth.xxxx does not exist". In fact this file DOES exist but maybe X creates it and the timing is off, not sure. Anyway, the number changes as X creates a new file and I end up with a bunch of them I have to delete, except for the latest one. I understand the statement enable_xauth=1 in /usr/local/bin/startx is what enables or requires xauth and is related to this file, but do I need to do xauth? What are security implications of not doing xauth? This machine is a workstation and has Internet access but is not exposed to the Internet (inbound).

Thanks in advance.
 
Your server process is exiting abnormally for some reason, because when you log out, reboot, or shutdown the session, the .serverauth.$$ file for that session should be deleted. The number $$ is the process ID of your session process, and that's why it changes for each session. I never have more than one .serverauth.$$ in my home directory, and it's only there for as long as the session is running. You should never have to delete these files manually; the session process which creates it should also delete it when it exits.

Make sure you enable D-Bus in /etc/rc.conf with dbus_enable="YES". To ensure that everything exits normally, your .xinitrc should look something like this:
Code: 
exec ck-launch-session dbus-launch --exit-with-session startkde

This is to start KDE. To start MATE instead, replace the word "startkde" with "mate-session" -- use whatever the session script file name is, for your particular window manager.
 
Thanks for the reply - dbus is enabled and my window manager x11-wm/cwm does not require or know anything about dbus so I don't think that's the tie-in. x11/xorg does not require dbus either.
If I had a DE, those calls in .xinitrc would certainly be needed.

Changing enable_xauth=1 to enable_xauth=0 in /usr/local/bin/startx "fixes" the problem but really is masking the issue.
 
Yes. You might have stale processes eating up memory, or duplicate processes running at the same time. Or, when you shutdown, the machine is halting before the process can exit and delete its PID file as it normally should do. Are you starting X, then logging out, and then restarting X again, before eventually shutting the whole machine down? If you type ps -f from a root shell prompt, you should see only one process running /usr/local/bin/X while your window manager is running, and you should see no such process when the window manager is not running.

What does your .xinitrc look like? What window manager are you using? What does your ps -f output look like?
 
As regular user, no x running:

PID TT STAT TIME COMMAND
48000 v0 R+ 0:00.00 ps -f
84602 v0 S 0:00.05 -tcsh (tcsh)


As regular user, x is running:

PID TT STAT TIME COMMAND
48168 v0 I+ 0:00.01 /bin/sh /usr/local/bin/startx
49353 v0 I+ 0:00.00 xinit /home/paul/.xinitrc -- /usr/local/bin/X :0 -auth /
49709 v0 I 0:00.01 cwm
50361 v0 I 0:00.01 xclock -digital
84602 v0 I 0:00.06 -tcsh (tcsh)
50797 0 Ss 0:00.01 tcsh
52581 0 R+ 0:00.00 ps -f


Root terminal, x running:

PID TT STAT TIME COMMAND
82399 u0 Ss+ 0:00.00 /usr/libexec/getty 3wire ttyu0
49475 v0 S 0:02.81 /usr/local/bin/X :0 -auth /home/paul/.serverauth.48168 (
81447 v0 Is 0:00.02 login [pam] (login)
81582 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1
81737 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2
81923 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3
82033 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4
82173 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5
82198 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6
82354 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7
50983 0 S 0:00.01 su -
51082 0 S 0:00.01 -su (csh)
52517 0 R+ 0:00.00 ps -f


And finally, my .xinitrc

xrdb -merge ~/.Xresources
xmodmap ~/.Xmodmap
~/.fehbg
xclock -digital &
exec cwm
 
I'm wondering if the & character in xclock -digital & might not be turning the whole script into a daemon process which never terminates. Just to test the idea you might try taking the xclock line out of .xinitrc, and turning xauth back on, just to see if the problem has gone away. Then if that works, you could try xclock -digital from a command prompt, just to see if the terminal "hangs" after the command is entered. If it doesn't hang, then you could put the line back into .xinitrc, but without the &.
 
Thank you - your post prompted me read the man page for xinit and their example showed an "&" after everything that needs to be backgrounded. So...here is my revised .xinitrc and it works fine, no more error message :). I also changed, per the man page, the "xrdb" statement to say "load" instead of "merge". I had been carrying that entire .xinitrc over from Linux and wasn't sure how this was supposed to be done on FreeBSD. Wanted to be sure I didn't carry any "Linuxisms" over...


xrdb -load ~/.Xresources
xmodmap ~/.Xmodmap &
~/.fehbg &
xclock -digital &
exec cwm
 
Welcome. Glad you got it working. Most interesting. Now I'll know what to do if I ever need to have an .xinitrc with more than one line in it. :beer::beer:
 
On Linux, I went back and forth between DE's and WM's - never could settle until I finally went KDE on openSUSE. Loved the DE, BUT...since I was drinking the whole Linux koolaide poison anyway, I thought it was fine. Now that I have switched to FreeBSD completely, I am much happier with the simplicity of a (very) simple window manager and setting up the environment myself, without massively complex desktop environments doing it for me.

All that to say why I have a multi-line .xinitrc :)

Thanks again for pointing me in the right direction.
 
I'm still in the mindset where I want massively complex desktop environments to do it for me, but that may change eventually. Wish I could find a DE for FreeBSD that had fewer Linuxisms in it, but that seems to be getting harder and harder to find. On Linux I'm happy to use MATE but it does not work well on my 32 bit system. Even KDE has Linux or Linux-inspired components in it. Hard to buck the system.
 
So that didn't work, no worries, not a show stopper. I need those lines in my .xinitrc because my window manager doesn't have a way to start anything on it's own. Will dig into it more but for now I toggled the enable_xauth flag to "0" to get rid of the messages and build up of auth files...

EDIT - did a bit of googling - ended up deleting the auth file(s) and my .Xauthority file. This seemed to work, will keep an eye on it. I also re-enabled the auth flag in /usr/local/bin/startx
 
Checked out xinit in the manual and according to that, your modified .xinitrc sure looks like it should work.
 
Sevendogsbsd said:
Every time I start X, I get the error message saying "/home/myuser/.serverauth.xxxx does not exist"
Click to expand...

as $XAUTHORITY overrides the xauth() -f option in the startx script pointing to a ~/.serverauth.xxxx file to store the secret key, the error can appear when xauth finds ~/.Xauthority not writable by the current user, which typically happens after starting an X session as root from inside /home/$USER, like for example after going root with su -. I'd try reverting changes in the startx script (it's not good practice to disable MIT-MAGIC-COOKIE-1 authorization if PC is exposed to Internet, and has stuff like ssh and tigervnc ports opened, see Xsecurity(7)) and recursively
enforcing ownership for your standard user on your $HOME by doing:
chown -R $user:wheel /home/${user}
 
Thanks for the info Sensucht94 - I have never started X as root, however I routinely use x11/uxterm to su - to root while logged into x as my normal user. I did revert the changes to the startx script. Since deleting ~/.Xauthority and the last ~/.serverauth.xxxx x couldn't find, although it created it, all seems to be well.
~/.Xauthority and ~/.serverauth.xxxx have been recreated and I can run startx without the error message.

EDIT - forgot to add: my PC is not exposed to the Internet at all, except outbound. Regardless, I understand and agree about the x authorization. Better to err on the side of caution.
 
You must log in or register to reply here.
Back
Top