At startx, it invokes startxfce4, which dumps several messages, then fails.
It does not do this every time, but is intermittent.

The message which seems to be relevant is the one about ICE:
"_IceTransSocketUNIXCreateListener: ...SocketCreateListener() failed".

If I run the exact same "startx" afterwards, it will succeed. It also will succeed on the first try on other days.
The only special thing about this day, is that the last time I used this console with X, it was as a different user.

The start log files that are created (due to my instrumenting startx) look to be the same as any other day. I have them, but there is nothing interesting there.

This problem is the same problem of a previous thread about DISPLAY already found at startx, but I finally determined that X already running was a NORMAL message, and was not the problem. I marked that thread as solved to get rid of it.

This is not a show stopper, but may be indicating that something is not setup right.
For that reason, I want to find out what is wrong.
I have run Linux since the 1990's, and have not had much trouble with ICE. I suppose that leaves me ill equipped to know what to do to fix it.
This is a new installation of Slackware 15, and the things that could have gone wrong just about includes the entire installation. I have been fighting with it on various issues since Feb. Mostly things that someone decided they were not using, so they went and deleted that capability in the kernel, or some new version of software with a bad attitude about compatibility.

I have not found any commands for probing ICE authority or debugging what is bothering it.
If anyone knows what to look at, and can share that, then Thank You.

Aside: Do not search the web for "ICE authority" as you will get numerous sites concerning "Immigration" and the Federal Gov..

I suspect that what is happening is that your user identity switches are leaving your .ICEauthority file in the possession of the other user so tht you then have no access to it. This file contains a cookie that X applications need to share. The file might be located in your home directory or in /tmp or /run depending on your distro. If you can find it and delete it, X will create a new one for you in your own name.

It happened again, right after having used the other user.
When I run startx again, it failed again, but with a different failure message (one I did not even understand).
When I ran startx for the third time, then X started up.

I had deleted the ICE hidden files of both users, and recreated them using touch.
The ICE file of user2 was empty, it had no cookies in it. This was verified after having started X for that user, while that user was running X.
The ICE file of user1 had cookies, but they were using an old system name that I had changed months ago. I had found out that having an underline in the system name would not be accepted by SOME tools, so I had to remove the underline.

As of this posting, both user1 and user2 have used startx, but the /home/user1/.ICEauthority files are empty.

I do not know where this new version is putting the ICE files. I was hoping someone would tell me. I have looked in the obvious places.
Isn't this system supposed to be able to support multiple users ?
How can one user end up owning the ICE validation file of another user ?

Distro is Slackware 15.
My older Slackware 14.2 did not have this problem.

======
Thank you for mentioning /run/user.

I looked in /run/user and discovered a directory with an ICEauthority file.
It has cookies that are recent, and it is owned by user2 as it should be.

All the /run/user directories have read and execute permission for user,other,group.
There is a subdirectory for root, and user2. There is NOT a directory for user1.

I logged in another console as user1, and the user1 directory did show up in /run/user/, with the proper ownership.
I did startx on user1, so I now have both user1 and user2 running X at the same time.
In the user1 directory under /run/user/ I did see an ICEauthority file, with cookies in it, and the proper ownership.

I am going to delete the /home/user*/ICEauthority files.

So how are they interacting?
Now what?

I have deleted the old style ICE files in the user account.

The ICE failure is still happening. The failure rate is now about 2 times every 7 starts.
I have watched the directories and files be created in the /run/users directory.
I have logged in users in various orders, and have done startx for both.

There is no obvious relationship between one user having been logged in and the failure occuring.
That appears to have been an accidental appearance due to failures seemingly occurring when
switching from one user account to the other. Further testing has shown that it does not matter
who was the last user.

I have not been able to discern anything about what would make ICE fail, or even what
possibilities need to be checked.

This has gotten more frequent now, happening every day for the last 4 days.
I have varied the pattern to try to discern anything that I can.

It seems that the failure only occurs for the first attempt to startx after booting.

I have had a similar problem for years with TiMidity.
TiMidity is started at boot, and intermittently could not read its config files at boot time, and would fail to start.
Repeating the start of TiMidity would always work. It could always read its config files on the second attempt.
Years ago I modified its boot script to test that it started, and to repeat its start if it failed the first time.
I had tried to pre-read the config files in the script, but that did not affect the failure of TiMidity.
This first occurred in Slackware 14.2, years and years ago.

It appears with ICE now because ICE changed where it stores the ICE files.
I do not know what it is about these two things that make them fail to execute a simple file command.

This hard drive is 2 TB, and is not that old. I think this first occurred with the previous hard drive.
Any suggestion that it is related to hardware is going to have to explain why it consistently hits these
particular usages only, and does not show any effects with any other usage. I do not get general errors.

Right now, the first read of a directory is terribly slow, which I believe is due to having a large partition.

I shutdown every night, and restart the next day.
It is not safe for me to leave this machine running due to a particular hostile person here.

With all the files read during boot, I have only witnessed this kind of problem with these two.

Do these operations wait for any slow directory first reads, or would they time out for some reason ??

Did a fsck of that particular partition.
>> fsck.ext4 -n -f /dev/sda9

It found a few weirdnesses, which were not readily explainable.
Note that it was read-only.

Looking at /etc/fstab, I noticed that it was ext3. I thought I had converted all the ext3 drives to ext4 (by making a new filesystem and copying everything to it).
Try to get any ext tool to tell you if a filesystem is ext3 or ext4. They will not.

Rebooted back to Slack 14.2, which is on a different partition.
Did a fsck of sda9. It found nothing wrong.
I forced fsck to check that partition different ways, using -f, using -D, using -p, and it found nothing wrong.
Still could not get any tool to identify it as ext3 or ext4.
It has a journal.
It has options extent, and dir_index, so it MUST be ext4.

The fstab on sda7, had sda9 as ext4.
I fixed the fstab on sda9, to also mount it as ext4.
I check that partition with debugfs, and did fsck a couple more times to make sure it was happy.
They found nothing wrong.

So, gotta see what effect this had.
Rebooted back to sda9.
Logged in and tried startx, ... it failed just as before.
It work on the second try, just as before.
This machine has been rebooted twice, and warmed up for a hour now, so it cannot be anything like that.
All this had no effect at all.

Having ext3 in the fstab, will still use ext4 driver to mount the filesystem.
It apparently does not even notice that it was mounted as ext3, even though having extent and dir_index options.
During the checks there were many files that were allocated using extents.
There have been no obvious complaints from the ext4 driver of any kind, anywhere.

And yet the same problem with creating the ICE authority file still persists, but only on the first attempt.

Note: For the ICE problem, as the file is newly created, it probably exists only in the file cache (in memory), and accessing it would not involve actual hard drive movement at all. !!
I am starting to suspect that file system journal. When ext3 was first installed is just about the time that TiMidity started having read-config problems.

Moderator: Is there another forum that might more appropriate to getting some response to this question. ?

This problem has occurred for other users, on other distributions, and even other posts in LinuxQuestions.
It shows up on Ubuntu, and OpenBSD forums.
It has been happening since 2005.
Bug reports have been filed with X, and have been dismissed due to "lack of interest".

Nobody has discovered what is happening.
The symptoms are universal.

Trying to startx will fail on the first try with an ICE failure, and will succeed on the second try.

I have downloaded the ICE library source, and cannot find the error messages in the source code.
Even with instrumenting the startx, startxfce4, I cannot find exactly WHO is dumping these error messages.
I have yet to find where in X it is calling ICE library.


The sites with the best information.

***
"https://comp.os.linux.x.narkive.com/RTE9NDuY/i-have-to-log-in-twice"

Allan Adler may have found something:
Quote: "I also found, in the same search, some source file Xtranssock.c at
http://cvsweb.xfree86.org/cvsweb/xc/...ock.c?rev=3.74
which explicitly contains what seems to be very close to some of these
error messages."

I have not yet found any such source file, or comparable source file in Slackware source (but do not have the whole source, as I have to get it in dribbles, as you have to know which source tar file you want to look at, and then unpack it somewhere.)


***
"https://www.linuxquestions.org/questions/slackware-14/unable-to-establish-ice-listeners-cannot-socket-error-312876-print/"
Note: that there is no reasoning about why an arbitrary root owned file in your home directory would affect some library that is not concerned with that file.
There is the possibility that ICE does something dumb that depends upon being able to stat "every" file in the user home directory, but that would be really dumb.

As this is intermittent enough as it is, it is difficult to diagnose anything to fix if I should disturb the trigger conditions.

***
"https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/516331"
Many users adding that they have same problem.

Have found the X source tar files.

libICE-1.0.10
This does not contain the error message strings.
It does invoke xtrans, using the define "ICE_t"

xtrans-1.4.0
This is invoked by several parts of X-windows. It creates functions with unique names, that are created by macro functions.

The error has "_IceTransSocketUNIXCreateListener", but that does not appear anywhere.
Within xtrans, there are config tests
#ifdef ICE_t
#define TRANS(func) _IceTrans##func
#endif
#ifdef ICE_t
UNIX_DIR= "/tmp/.X11-unix"
UNIX_PATH= "tmp/.X11-unix"
#endif
#ifdef ICE_t
UNIX_DIR= "/tmp/.ICE-unix"
UNIX_PATH= "tmp/.ICE-unix"
#endif
Both of these directories exist.

Within xtrans,
There is a function "TRANS(SocketUNIXCreateListener)", which will expand to "_IceTransSocketUNIXCreateListener", which is what appears in the error message.
This function can fail with the error code TRANS_CREATE_LISTENER_FAILED, in several ways, all using the same error code.

It tries to create the directory UNIX_DIR, which is "/tmp/.ICE-unix".
This dir already exists, is owned by root, and contains many old sockets (i.e. "1234=") from many users, including some from root.
It will try to create it with root ownership, and mode 01777 (with sticky dir bit).
If the user is not root the dir create will fail.
It will check the directory owner and mode, and if it does not like them, will attempt to change them, and if it cannot will fail.
The UID must be 0. The mode (passed by param) is complicated. The current mode must not be more permissive than (0077), and it must have write enabled (0022). Also the sticky bit is requested or UNIX, and if it is not set, and if the user is not root, the check will fail for that reason alone.
The observed /tmp/.ICE-unix dir has every mode bit set ("drwxrwxrwt"). It seems to have the same mode as /tmp and /tmp/.X11-unix.
For the above there is an option FAIL_HARD that will cause -1 to be returned on fail. I could not find it being defined, so must assume that the "warning message" alternative is in force on fail.
As this cannot be changing with every other attempt, it is not likely the problem.

Next the CreateListener will create a name from the PID in this directory using UNIX_PATH, example "/tmp/.ICE-unix/1077". As the PID are unique, this ought to be unique.
There are many sockets in "/tmp/.ICE-unix" directory with such a name structure.
It will use this with "set_sun_patch" to form the sockname, and if that fails, it will return TRANS_CREATE_LISTENER_FAILED. As this is mostly string concat and port checks, it is not our problem.

It will next call "TRANS(SocketCreateListener)" a name that appeared in the error messages.
If it fails it puts out an error message that looks like one that appeared in the error messages, "SocketUNIXCreateListener: ...SocketCreateListener() failed".
This will pass the sockname to bind, passing "/tmp/.ICE-unix/1077" as the addr.
Bind will try to create this socket in the filesystem. When it fails we get the error message we see.

I can now see why this fails the way it does.
A user logging after a fresh boot will likely have a PID that is the same day after day.
The old sockets are NOT BEING REMOVED from "/tmp/.ICE-unix". Hitting one that you own as a user probably is allowed by bind (they don't say). Hitting an old socket owned by someone else is not likely to succeed. Hitting an old socket owned by root, is going to fail.

This also explains whey it works when you try again. Trying again is a new task, which will get the next PID. YOUR PID HAS CHANGED. The new socket name will be different by 1, and will miss the old socket that it hit on the first attempt.

This also explains why the one user, if he did not startx right away, but did some other things first, said that allowed him to startx without errors. By doing that he is getting a different PID from the usual, and thus not hitting the old socket that is in his ICE directory.


This distribution, X, xfce4, all have the opportunity to fix this problem.
** X could make sure to remove the old sockets upon shutdown.
** xfce4 could clear its socket on shutdown, it is the same PID.
** The distribution could clear this directory upon shutdown, and upon startup, as no sockets will carry over across reboot.




***
From the ICE changelog:
Date: Tue Jun 14 16:09:46 2016 -0400

authutil: support $XDG_RUNTIME_DIR/ICEauthority

If we find that $XDG_RUNTIME_DIR is set (and $ICEAUTHORITY is not), then
the ICEauthority file is stored in the XDG_RUNTIME_DIR instead of the
home directory, and without a leading dot.

I have modified my Slackware script /etc/rc.d/rc.K
New rc file, /etc/rc.d/rc.clean_sockets