This topic was moved from 'Slackware-Installation' to the 'main' Slackware forum in hopes of wider response. I'm sorry if that irritates some folks, but I consider it necessary.

For several years now, and on at least six different computers running Slackware of various versions (usually with xfce), I have experienced intermittent failure of the 'startx' command on cold boot into a user account. Currently this happens on three different computers with Slackware64 14.2 with multilib and xfce4. Typically, startx fails on first and/or second call, then usually succeeds by third trial.

When startx fails, it always results in black screen for 2-3 seconds, then returns to user prompt ($), with (consistent) message like,

" ...
...
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 2 13:47:31 2019
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
resize called 1920 1080
/usr/bin/startxfce4: X server already running on display :0
_IceTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_IceTransMakeAllCOTSServerListeners: server already running
xfce4-session: Unable to establish ICE listeners: Cannot establish any listening sockets
xinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file."

Every time it fails, it includes the 'claim' that the 'X server is already running on display :0", which seems false, as it happens also on cold boots.

I've looked thru the log file without success in finding a 'culprit', probably due to my own lack of knowing what to look for. The log file typically consists of many 'trials' for 'missing screen section', trial modelines, etc etc. When successful, the logfile just ends with a last line like,

"...NOUVEAU(0): Modeline "1280x800"x0.0 1280 1328 ... " etc,
with no lines following.

I read that 'NOUVEAU' is x's name for an emulation of NVIDIA, which board seems to be in all my machines. I have not tried 'new drivers' and I have doubts that they would solve this.

My monitor resolutions are all 1920x1080.

Hazel commented that maybe (1) I was entering a runlevel other than '3'. Checking, I find this not to be the case, both in the boot messages or in /etc/inittab. - or, (2) If X is running should be able to find it with (probably) alt-F7. I've tried that when returned to the boot line, both 'Alt-F7' and 'Ctrl-Alt-F7'. No response.

I have checked for the existence of a '.X0-lock' file (or similar) - no file like that exists until X boots successfully.

I looked on the x webpage (www.x.org) at the Faq, especially one question that duplicates the 'already running' message. None of the remedial actions suggested there have any positive effect. There is no 'lock file' at all until X is started.

One other person (not slackware forum) suggested booting x with 'startxfce4'. This 'works', but leaves some menu items in xfce disabled. So is not satisfactory.

Given that this has been going on for years, I'm a bit frustrated. I don't find very much discussion of this problem here or elsewhere online. This seems strange, since it seems 'built-in' to this household, and has for several years of Slackware use. My slackware installs are always from the DVD (earlier CD's) - by the book. I've not upgraded a kernel - but this happened long before that was relevant.

If anyone has experience with this problem and found a resolution, I would be very interested to hear about it.

Thanks - jrc

I confirm the behavior.

In my case the problem started about a month ago and only on my Lenovo T400 laptop. On my office system I never experience the issue. I am using 14.2 and Xfce. Both systems use the i915 video driver.

My solution thus far with the laptop is to wait a few seconds after the login prompt appears. Somewhat a "let the dust settle" approach. I won't say my waiting resolves the problem as this is an n=1 occurrence and I have not tried to dig deeper.

I have the haveged daemon running from rc.M so unlikely to be some kind of entropy issue.

I thought I had done something peculiar to cause the behavior. Now that you report something similar I am curious about a possible common root cause.

I've seen this dbus-launch chaining in .xinitrc cause problems before:
As startxfce4 will start dbus using the -- IMO more reliable -- eval `dbus-launch` method, the above is unnecessarily complicating things. I'd simplify it to:
Even if it doesn't solve your issue, you'll have made the startup environment a little cleaner.

I've changed my xinitrc files. We'll see how that goes, although in my use case I don't always see the problem on the laptop.

I've also changed my .xinitrc per GazL's suggestion (although, I think there's a typo there, as the $DESKTOP_SESSION test didn't seem complete - I ignored that). But also, this has been intermittent for a _long_ time. I've never been bothered enough to look into it, because a second invocation of startx alsways succeeded.

1 members found this post helpful.

Oops, cut and paste error, Ill go back and fix it. Sorry about that.

I have this behavior intermittently on one of my Slackware units.

I haven't experienced this issue and have little/no knowledge about this but that doesn't stop me from making a wild guess...

I notice that a socket exists in /tmp/.ICE-unix. Could the permissions and/or persistence of that directory/socket in /tmp cause the problem, even on a cold boot?

I configure /tmp to tmpfs, so on my system the socket file is always deleted on reboot/halt. Yet I intermittently see the reported problem on my laptop. Perhaps the OP might want to look at that -- boot to init 1 and delete everything in /tmp if not using tmpfs.

Hello Upnort, Jrch, and Hitest

Could you upload the x error log?

Regards,
Ozan

I must be lucky.

I've not encountered this.

Actually during the early stages of Plasma5 I had to explicitly add "dbus-launch --exit-with-session" in order to fix the progress bar in the splash screen: https://git.slackware.nl/ktown/commi...33dded7eefab8b
Never tested whether it is still required.

Does startkde not contain an eval `dbus-launch -sh-syntax`? I'd look myself but I don't install the KDE sets.


As I remember it, the issue is that to run properly the dbus-launch has to be run within the console-kit session, but when you exec chain them like that whatever you pass to dbus-launch to be exec'd doesn't get a completely clean process environment to run in.

This caused a problem for me a few years ago when X noticed that the window manager trying to connect had the same PID as an existing X11 connection because dbus-launch had exec'd it without forking and that specific window manager didn't fork itself into the background on startup either, so they both had the same PID. The result was that the X connection from the window-manager was refused.

I find that using the 'eval' method instead of chaining the launch commands avoids these sorts of complications. So, now I always have it set up like this:

xinitrc runs ck-launch-session /usr/bin/somescript
/usr/bin/somescript does eval `dbus-launch --sh-syntax --exit-with-session` (if the DE startup doesn't do it itself) and then exec's the window-manager/DE.

I'll attach my generic window manager starting script as an example in case anyone is interested.

I appreciate just knowing that others have the problem. I guess knowing that one can eventually get x going by repeating 'startx' makes it of lower priority - it did for me.
Trying to attach 'startxfail-log-jrch.txt' here..
jrc

Attached Files

startxfail-log-jrch.txt (32.0 KB, 22 views)

Saturday evening,

I'm trying the .xinitrc modified as per Gazl; so far on two computers, 2 or 3 cold boots startx works flawlessly. Not a conclusive test yet, will report as more trials done.

Thanks for everyone's comments.

jrc