[SOLVED] DISPLAY environment variable is unreliable

selfprogrammed · 08-03-2023, 09:30 AM

I have been having a problem with the DISPLAY environment variable.

It started when I first installed Slackware 15 (months ago).
Some of the programs could not detect that X-windows was running, and would immediately shutdown.

Now, I am getting the opposite problem.
Trying to startx, the xfcestart script is detecting that X-windows is ALREADY running (it is not)
and exiting. This is right after booting the system, and my initial login.
Today, I had to run it three times before XFCE4 and x-windows would come up.

After the first failure, I printed out $DISPLAY,
>> echo x"$DISPLAY"x
and got back "xx"

Tried startx again, and it failed a second time.
I cannot see the messages now due to this new screen setup where it uses the same system console for X.
Thus, I cannot see any of the error messages from startx.

Tried startx a third time (NO CHANGES TO ANYTHING), and this time it started.

What has happened to BASH that now environment variables are so unreliable, or are they statistically based now. I have tried to diagnose this several times already.
The only thing I can come up with is that BASH is failing in its test, maybe due to its environment variable database pointers being mis-handled.

I have tried putting a line in the profile script to set
DISPLAY=

just to initialize the thing.

It could be 2 or 3 weeks before it fails like this again.
Random experiments are not going to explain anything.

This is machine where I often switch back to the Linux 4.4 to get some work done reliably, and I am not seeing any such problems there. The Linux 4.4 is rock solid reliable.

lostintime · 08-03-2023, 10:12 AM

The $DISPLAY environment variable is set from the X server. If X is not running then the variable is not set.

Launching X from the console through startx requires an xinitrc file to be defined. If the user has not explicitly created a $HOME/.xinitrc file with xwmconfig, then the default xinitrc will be used. The default xinitrc is found in /etc/X11/xinit. In Slackware this commonly is a sym link to either the KDE or Xfce xinitrc script.

With respect to other environment variables, the system /etc/profile file is the beginning place to create variables. More variables get populated through /etc/profile.d scripts. When using bash then other variables might get set through the various bash startup files.

After logging in at the console the $DISPLAY variable does not exist. That variable gets created when the X server is launched from one of the xinitrc files.

A first wild guess is check if the sym link exists in /etc/X11/xinit. If not then as root run xwmconfig and select a system wide default desktop. Or run xwmconfig as normal user to create $HOME/.xinitrc.

I hope that helps.

selfprogrammed · 08-03-2023, 10:16 AM

I have a quad processor.
The Linux 4.4 probably does not make much use of that fact.
The more that the changes to Linux try to take advantage of multi-processors, the more likely they are going to create problems that look EXACTLY like this.

selfprogrammed · 08-03-2023, 10:22 AM

We were both typing at the same time, that was not an answer to your post.
Thank You. I will look into those lines.

I have been trying to populate my user accounts on the new system from the old system. That involves copying files, including .config files, in order save all the history and passwords among other things.
There is a massive amount of state that I would not want to spend a year trying to recreate. I am still trying to recover state lost from the last update to Slackware 14.2. I had programs from then that I still have not gotten back yet.

selfprogrammed · 08-03-2023, 10:46 AM

There is no user defined .xinitrc.
I see some test of some file not found at every startx execution (but cannot look at it right now because X-windows uses the same console as the startup, thus preventing me from seeing any such messages once is actually starts). I assume that is normal.

These were found:
/etc/X11/xinit/xinitrc ==> xinitrc.xfce4

I compared this xinitrc.xfce4 against the old system.
They differ only in that they removed some lines "modified to work aound xfce4session bug"
where they conditionally started xfce4 thus:

From Linux 4.4 xinitrc.xfce, which is not in the xinitrc.xfce from Slackware 15.

Code:

#  xinitrc.xfce - modified to work around xfce4session bug
#                 https://bugzilla.xfce.org/show_bug.cgi?id=8841


if [ -z "$DESKTOP_SESSION" -a -x /usr/bin/ck-launch-session ]; then
  exec ck-launch-session dbus-launch --exit-with-session /usr/bin/startxfce4
else
  exec dbus-launch --exit-with-session /usr/bin/startxfce4
fi

Thought:
This is a quad-core multi-processor.
Is it possible that the xinit is running on a different core and is in a race against the startx tests.
That is EXACTLY what this looks like. Otherwise, it would be the same result every time.

selfprogrammed · 08-03-2023, 11:06 AM

Poking around I have found an xfce4-session.verbose-log.

The tail end (last 50 lines) of the log (I assume it is appended each day).
There do not seem to be any obvious way to identify one day or session from the next. I expect some of the last to be from the current session (that worked), but where the two failed startx logs are (if they are there at all) is up to the reader guessing.
This must scrolled to see the ICE error at the end:

Code:

TRACE[xfsm-properties.c:680] xfsm_properties_remove(): -> Removing (DiscardCommand)
TRACE[xfsm-properties.c:555] xfsm_properties_set_uchar(): -> Set uchar (RestartStyleHint, 0)
TRACE[sm-layer.c:304] sm_save_yourself_done(): Client Id = 2f2a4a99d-d5d0-4ee0-8e57-2304f10ec824, received SAVE YOURSELF DONE [Success = True]

TRACE[xfsm-manager.c:1295] xfsm_manager_save_yourself_done(): enteringTRACE[xfsm-manager.c:428] xfsm_manager_handle_failed_properties(): Client Id 2f2a4a99d-d5d0-4ee0-8e57-2304f10ec824 exited, removing from session.
TRACE[xfsm-manager.c:1130] xfsm_manager_save_yourself_global(): enteringTRACE[xfsm-manager.c:303] xfsm_manager_set_state(): 
state is now XFSM_MANAGER_SHUTDOWN
TRACE[sm-layer.c:304] sm_save_yourself_done(): Client Id = 28f424273-5410-4f1d-8858-142cb04cf638, received SAVE YOURSELF DONE [Success = True]

TRACE[xfsm-manager.c:1295] xfsm_manager_save_yourself_done(): enteringTRACE[sm-layer.c:304] sm_save_yourself_done(): Client Id = 2a33d8a6d-793b-4114-aaa1-4830e52ba217, received SAVE YOURSELF DONE [Success = True]

TRACE[xfsm-manager.c:1295] xfsm_manager_save_yourself_done(): enteringTRACE[sm-layer.c:304] sm_save_yourself_done(): Client Id = 2bb88ff3f-74f7-4405-96db-c86aac1021ab, received SAVE YOURSELF DONE [Success = True]

TRACE[xfsm-manager.c:1295] xfsm_manager_save_yourself_done(): enteringTRACE[sm-layer.c:304] sm_save_yourself_done(): Client Id = 2446bc1e0-bd06-4246-aa51-e3ad95011f96, received SAVE YOURSELF DONE [Success = True]

TRACE[xfsm-manager.c:1295] xfsm_manager_save_yourself_done(): enteringTRACE[sm-layer.c:304] sm_save_yourself_done(): Client Id = 225bd5e2c-7f22-4595-bb83-7a5c40bc3781, received SAVE YOURSELF DONE [Success = True]

TRACE[xfsm-manager.c:1295] xfsm_manager_save_yourself_done(): enteringTRACE[sm-layer.c:304] sm_save_yourself_done(): Client Id = 21f768c5c-fea8-4f03-b018-10c338da4d24, received SAVE YOURSELF DONE [Success = True]

TRACE[xfsm-manager.c:1295] xfsm_manager_save_yourself_done(): enteringTRACE[sm-layer.c:232] sm_interact_request(): Client Id = 248b61885-c63f-4607-b266-aae7acfaf5e4, received INTERACT REQUEST [Dialog type = Normal]

TRACE[sm-layer.c:246] sm_interact_done(): Client Id = 248b61885-c63f-4607-b266-aae7acfaf5e4, received INTERACT DONE [Cancel shutdown = False]

TRACE[sm-layer.c:290] sm_save_yourself_phase2_request(): Client Id = 248b61885-c63f-4607-b266-aae7acfaf5e4, received SAVE YOURSELF PHASE2 REQUEST

TRACE[xfsm-manager.c:1271] xfsm_manager_save_yourself_phase2(): enteringTRACE[xfsm-properties.c:489] xfsm_properties_set_string(): -> Set string (Program, /usr/bin/kactivitymanagerd)
TRACE[xfsm-properties.c:489] xfsm_properties_set_string(): -> Set string (UserID, wes)
TRACE[sm-layer.c:232] sm_interact_request(): Client Id = 2c5100b8b-8a36-42fb-973a-5caff2991701, received INTERACT REQUEST [Dialog type = Normal]

TRACE[sm-layer.c:246] sm_interact_done(): Client Id = 2c5100b8b-8a36-42fb-973a-5caff2991701, received INTERACT DONE [Cancel shutdown = False]

TRACE[xfsm-properties.c:629] xfsm_properties_set_from_smprop(): -> Set strv (RestartCommand)
TRACE[xfsm-properties.c:680] xfsm_properties_remove(): -> Removing (DiscardCommand)
TRACE[xfsm-properties.c:555] xfsm_properties_set_uchar(): -> Set uchar (RestartStyleHint, 0)
TRACE[sm-layer.c:304] sm_save_yourself_done(): Client Id = 2c5100b8b-8a36-42fb-973a-5caff2991701, received SAVE YOURSELF DONE [Success = True]

TRACE[xfsm-manager.c:1295] xfsm_manager_save_yourself_done(): enteringTRACE[xfsm-manager.c:1554] xfsm_manager_maybe_enter_phase2(): Client Id = 248b61885-c63f-4607-b266-aae7acfaf5e4 enters SAVE YOURSELF PHASE2.

TRACE[xfsm-properties.c:629] xfsm_properties_set_from_smprop(): -> Set strv (DiscardCommand)
TRACE[sm-layer.c:304] sm_save_yourself_done(): Client Id = 248b61885-c63f-4607-b266-aae7acfaf5e4, received SAVE YOURSELF DONE [Success = True]

TRACE[xfsm-manager.c:1295] xfsm_manager_save_yourself_done(): enteringTRACE[xfsm-manager.c:1573] xfsm_manager_complete_saveyourself(): Manager finished SAVE YOURSELF, session data will be stored now.

TRACE[xfsm-manager.c:1459] xfsm_manager_perform_shutdown(): enteringTRACE[xfsm-manager.c:303] xfsm_manager_set_state(): 
state is now XFSM_MANAGER_SHUTDOWNPHASE2
TRACE[xfsm-properties.c:555] xfsm_properties_set_uchar(): -> Set uchar (RestartStyleHint, 0)
TRACE[xfsm-properties.c:555] xfsm_properties_set_uchar(): -> Set uchar (RestartStyleHint, 0)
TRACE[xfsm-properties.c:555] xfsm_properties_set_uchar(): -> Set uchar (RestartStyleHint, 0)
TRACE[xfsm-properties.c:555] xfsm_properties_set_uchar(): -> Set uchar (RestartStyleHint, 0)
TRACE[ice-layer.c:99] ice_error_handler(): ICE connection fd = 20, ICE I/O error on connection

This is not the first time that I have seen ICE errors.
As it is another of those dynamic errors that come and go, the usual is to just try it again.

Perhaps some reader can compare this to their own log and identify what part of it is not normally there.

Addendum: Thinking about it now, those two failed startx sessions bombed out in the xfce4 start script, and probably did not touch this log at all.

selfprogrammed · 08-03-2023, 11:30 AM

I found the following in my /etc/profile, obviously from fighting with this problem before.
I do not expect that the export of a DISPLAY that supposedly does not exist would make a difference.
Also, it was acting up like this before this change was made.

The export with DISPLAY matches my profile from the old system.

Code:

# DISPLAY, May be fooling startx into thinking that x-windows is already running
#export PATH DISPLAY LESS TERM PS1 PS2
export PATH LESS TERM PS1 PS2

I did a
>> grep -i DISPLAY /etc/profile.d/*
and got nothing.
They are mostly comments of things that you could enable.

henca · 08-03-2023, 12:12 PM

Quote:

Originally Posted by selfprogrammed

I have been having a problem with the DISPLAY environment variable.

As lostintime explained, the DISPLAY variable is not supposed to be set until X has been started.

Quote:

Originally Posted by selfprogrammed

Trying to startx, the xfcestart script is detecting that X-windows is ALREADY running (it is not)

Are you sure? Maybe you have started X on another virtual console? You could also try to run startx and giving it another, free DISPLAY number:

Code:

startx -- :1

Quote:

Originally Posted by selfprogrammed

I cannot see the messages now due to this new screen setup where it uses the same system console for X.

Interesting messages might be found in /var/log/Xorg.0.log for DISPLAY :0, if you start at another display as I suggested the file will get a different number in its name.

Quote:

Originally Posted by selfprogrammed

Thus, I cannot see any of the error messages from startx.

Have a look at those log files.

Quote:

Originally Posted by selfprogrammed

What has happened to BASH that now environment variables are so unreliable, or are they statistically based now.

What makes you think that your problems are caused by environment variables?

Quote:

Originally Posted by selfprogrammed

I have tried putting a line in the profile script to set
DISPLAY=

just to initialize the thing.

Don't do that before starting X.

Quote:

Originally Posted by selfprogrammed

It could be 2 or 3 weeks before it fails like this again.
Random experiments are not going to explain anything.

If this problem occurs randomly I would suspect broken RAM (check with some memtest live media) or a heat problem. You could also study the output from dmesg to see if it says anything about CPU temperatures or ECC parity errors.

Quote:

Originally Posted by selfprogrammed

This is machine where I often switch back to the Linux 4.4 to get some work done reliably, and I am not seeing any such problems there. The Linux 4.4 is rock solid reliable.

Linux kernel 4.4 sounds like Slackware 14.2 rather than Slackware 15.0.

Quote:

Originally Posted by selfprogrammed

I have a quad processor.
The Linux 4.4 probably does not make much use of that fact.

What makes you think so? With top you can study how processes are put on different cores.

Quote:

Originally Posted by selfprogrammed

The more that the changes to Linux try to take advantage of multi-processors, the more likely they are going to create problems that look EXACTLY like this.

What makes you think that this would be caused by some kind of race condition? Today basically all CPUs have multiple cores, most people don't seem to have any trouble starting X on those.

Quote:

Originally Posted by selfprogrammed

I have been trying to populate my user accounts on the new system from the old system. That involves copying files, including .config files, in order save all the history and passwords among other things.

In my experience window managers and desktop environments are usually backwards compatible, making it possible to migrate from older versions to newer versions with the same home directory. However, those desktop environments are often not forwards compatible, that is things might break if you migrate a home directory from a newer desktop environment to an older version.

However, I only have experience from using entire home directories on different window managers and versions of desktop environments. If you are trying to only cherry pick some files and directories you might mess things up if you don't get all the files and directories that belong together.

Quote:

Originally Posted by selfprogrammed

There is a massive amount of state that I would not want to spend a year trying to recreate. I am still trying to recover state lost from the last update to Slackware 14.2. I had programs from then that I still have not gotten back yet.

Having reliable backups of your home directory might be a good idea.

Quote:

Originally Posted by selfprogrammed

Thought:
This is a quad-core multi-processor.
Is it possible that the xinit is running on a different core and is in a race against the startx tests.
That is EXACTLY what this looks like. Otherwise, it would be the same result every time.

I find it very unlikely that there is some race condition in starting xfce with startx. But logs needs to be studied to understand what goes wrong.

regards Henrik

bigbadaboum · 08-03-2023, 12:17 PM

$lspci | grep VGA ?
do you use amd-ucode or intel-ucode ?

Tonus · 08-03-2023, 12:56 PM

Quote:

Originally Posted by selfprogrammed

I have been trying to populate my user accounts on the new system from the old system. That involves copying files, including .config files, in order save all the history and passwords among other things.

Dude, that sounds like a very bad idea. I would suggest to upgrade the whole system rather than mix an old config with a new one from scratch.

Anyway, you need to identify exactly what you want to get from old system and ask advice on what to do from this point.

For instance : sync to a temporary profile your browser history and passwords, copy your .bash_history to get shell commands you're used to find there and so on.

lostintime · 08-03-2023, 02:26 PM

Updating a system from 14.2 to 15.0 requires a lot of testing because 15.0 introduced many changes. That said, many Slackers have updated to 15.0 in this manner. Conversely, there were so many changes in 15.0 that many people performed a clean install and then reconfigured their desktop settings.

Quote:

These were found:
/etc/X11/xinit/xinitrc ==> xinitrc.xfce4

That is a good start but the xinitrc files from 14.2 and 15.0 are different. Don't use the file from 14.2 in 15.0 because in 14.2 ConsoleKit was used and that package was dropped in 15.0.

Quote:

I found the following in my /etc/profile

Rarely should that file need local changes. The more common method to modify the output of that file is adding additional scripts in /etc/profile.d or in the user's bash startup files.

Quote:

This is a quad-core multi-processor.

The number of CPU cores irrelevant. Conversely, 14.2 lacked support for recent hardware that 15.0 does support. If the hardware functioned fine in 14.2 then updating to 15.0 should be good to go.

Quote:

I did a grep -i DISPLAY /etc/profile.d/* and got nothing.

That environment variable is not set in any startup shell script. That variable is set internally by the X server when launching X.

Quote:

I have been trying to populate my user accounts on the new system from the old system. That involves copying files, including .config files

If you have been copying user config files as root, then possibly the destination files now have root permissions and ownership. Just to be sure, as root perform the following:

chown -R name_of_user:name_of_user /home/name_of_user

Where name_of_user is the user account name.

Copying user config or "dot" files should mostly transfer okay. Most people should not need to copy files and instead should just leave the entire $HOME directory as-is. The location of the Xfce config files did not change between 14.2 and 15.0 but KDE changed much. Some specific features and options in Xfce changed but the config files should still function correctly.

Quote:

Poking around I have found an xfce4-session.verbose-log.

Possibly you tried to "cherry-pick" various packages when updating from 14.2 to 15.0. That seldom succeeds with any operating system.

There are several documents that provide instructions about updating from 14.2 to 15.0, such as UPGRADE.TXT and CHANGES_AND_HINTS.TXT.

The list of installed packages can be found in /var/log/packages, which in 15.0 is a sym link to /var/lib/pkgtools/packages/. If that list shows any patched packages from 14.2 then likely those packages need to updated to 15.0.

There might be a video driver issue (AMD, Intel, Nvidia), but thus far the problem description does not imply as such. The problem description implies broken packages. A reasonable solution might be to reinstall at least the Xfce packages. Might want to reinstall all of the X packages too.

henca · 08-03-2023, 05:35 PM

Quote:

Originally Posted by lostintime

The location of the Xfce config files did not change between 14.2 and 15.0 but KDE changed much. Some specific features and options in Xfce changed but the config files should still function correctly.

Yes, during the years I have learned to customize some files in /etc/profile.d where different versions of Slackware share the same home directories on something like NFS servers:

Code:

> fgrep slack14 /etc/profile.d/*
/etc/profile.d/kde.csh:setenv KDEHOME $HOME/.kde_slack142
/etc/profile.d/kde.sh:KDEHOME=$HOME/.kde_slack142
/etc/profile.d/wine.csh:setenv WINEPREFIX $HOME/.wine_slack142
/etc/profile.d/wine.sh:WINEPREFIX=$HOME/.wine_slack142

One day I might use something like environment modules to set different WINEPRFIX for 32-bit and 64-bit wine.

regards Henrik

selfprogrammed · 11-02-2023, 07:06 PM

Solved:
It is not the DISPLAY variable. The message about the DISPLAY environment variable is misleading, as it is a NORMAL. That message should be reworded so it does not look like it is part of the error messages that may follow it.

The fault is that the directory /tmp/.ICE-unix is filling up with stale sockets. The attempt to create a new ICE socket is failing because it hits one of the old stale sockets.
The system startup, system shutdown, and X-system are not cleaning up the stale sockets.

enorbet · 11-03-2023, 01:31 PM

I suggest you clear space for a clean, stock, FULL Recommended install for comparison. I have an old but still working 14.2 install with just an upgrade to a custom 5.15.19 kernel on a 6-core (12 including virtual) that runs just fine. I do keep a pristine 15.0 install on it's own partition but my Daily Driver is 15.0 with a custom 6.1.32 kernel... runs great. XDG sometimes gives me weird errors but seems to resolve itself. I don't get $DISPLAY errors that I recall.

selfprogrammed · 11-04-2023, 02:16 AM

THIS HAS BEEN SOLVED. Read my previous post please.
I have a solution. Others have confirmed similar symptoms and are testing the solution.
A patch to Slackware will be required.

The DISPLAY messages are confusing because there are two scripts involved, startx, and startxfce. They call one another. You could actually invoke either one, and it would invoke the other. The message about discovering that DISPLAY is a set and X-windows is already running is just the one script discovering that the other script already started X.
It is not an error at all, just a script being verbose about not having to call the other script. This prevents a loop, since it actually was invoked by the other script in the first place.