[SOLVED] startxfce4 finds DISPLAY is already set, on freshly booted system

selfprogrammed · 09-10-2023, 05:04 PM

This is an intermittent problem. It can happen 2 times out of 7 startx.
When "startx" is invoked, sometime xfce4 start finds that DISPLAY is already set, and errors out, wrongly.

I have added the following instrumentation to the startxfce4 file, to log the problem.
It has been inserted to execute where the script finds that DISPLAY is already set.

Code:

function debug_dump
{
  local log=~/startxfce4.log
  echo "DEBUG_DUMP: $0" | tee >> $log
  echo "DISPLAY=($DISPLAY)=" | tee >> $log
  echo "OPT param=$*" | tee >> $log
  echo "XFCE4_SESSION_WITH_CK=$XFCE4_SESSION_WITH_CK" | tee >> $log
  echo "SERVERRC=$SERVERRC" | tee >> $log
  echo "CLIENTRC=$CLIENTRC" | tee >> $log
  echo "XDG_CONFIG_HOME=$XDG_CONFIG_HOME" | tee >> $log
  echo "BASEDIR=$BASEDIR" | tee >> $log
  echo "XDG_DATA_DIRS=$XDG_DATA_DIRS" | tee >> $log
  echo "XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS" | tee >> $log
  echo "DISPLAY=$DISPLAY" | tee >> $log
  echo "XDG_VTNR=$XDG_VTNR" | tee >> $log
  echo "END_LOG\n"
}

It left this as a log today when startx failed again.
It appears there are two sessions logged.
Note that the first DISPLAY line uses =( )= as delimiters, the second does not.
startxfce4.log:

Code:

DEBUG_DUMP: /usr/bin/startxfce4
DISPLAY=(:0)=
OPT param=
XFCE4_SESSION_WITH_CK=
SERVERRC=
CLIENTRC=
XDG_CONFIG_HOME=
BASEDIR=/home/user1/.config/xfce4/
XDG_DATA_DIRS=/usr/local/share:/usr/share
XDG_CONFIG_DIRS=/etc/xdg:/etc/kde/xdg:/etc/xdg
DISPLAY=:0
XDG_VTNR=8
DEBUG_DUMP: /usr/bin/startxfce4
DISPLAY=(:0)=
OPT param=
XFCE4_SESSION_WITH_CK=
SERVERRC=
CLIENTRC=
XDG_CONFIG_HOME=
BASEDIR=/home/user1/.config/xfce4/
XDG_DATA_DIRS=/usr/local/share:/usr/share
XDG_CONFIG_DIRS=/etc/xdg:/etc/kde/xdg:/etc/xdg
DISPLAY=:0
XDG_VTNR=8

I have tried clearing it in /etc/profile
DISPLAY=
and that did not help.

DISPLAY was in an export stmt in /etc/profile, and currently that line has been edited to exclude DISPLAY from export. It is not set anywhere in /etc/profile anyway.

As this is first login after booting the system, where could it possibly be getting some value for DISPLAY ?
I want to check this location at shutdown, so I have to find out where it is kept.
I suspect there is not supposed to be one, but then I am back to question1.

When startx is tried a second time, it has succeeded.
After finding it set during the first failure, how is it finding DISPLAY to be cleared in the second.
I do not see any place where it is being cleared.

Where are system environmental variables set, how many are there.
If this was a user local environmental variable, I expect it would be more consistent, not so erratic.
Also, this is happening for two different users.

==============
>> grep DISPLAY /etc/*
>> grep DISPLAY /etc/*/*
Nothing obvious to me:

Code:

/etc/lynx.cfg:.h2 DISPLAY_CHARSET_CHOICE
/etc/lynx.cfg:# DISPLAY_CHARSET_CHOICE and ASSUMED_DOC_CHARSET_CHOICE settings correspondingly.
/etc/lynx.cfg:#DISPLAY_CHARSET_CHOICE:*
/etc/lynx.cfg:#              enabled if DISPLAY environment variable IS defined and
/etc/lynx.cfg:#              then printer/downloader will be enabled if DISPLAY
/etc/lynx.cfg:# for viewing image content types when the DECW$DISPLAY logical
/etc/lynx.cfg:# viewing image content types when the DISPLAY environment variable
/etc/lynx.cfg:#             defined when the user has the environment variable DISPLAY
/etc/lynx.cfg:#             (DECW$DISPLAY on VMS) defined.  If the NON_XWINDOWS environment
/etc/lynx.cfg:#             user DOES NOT have the environment variable DISPLAY defined.
/etc/lynx.cfg:# variable DISPLAY defined *at program start*, and equivalent to FALSE
/etc/lynx.cfg:# $DISPLAY environment variable is set, else if NON_XWINDOWS then command
/etc/lynx.cfg:# is allowed only if $DISPLAY environment variable is not set, if absent or
/etc/lynx.cfg:#ENABLE_LYNXRC:DISPLAY:OFF
/etc/profile:# DISPLAY, May be fooling startx into thinking that x-windows is already running
/etc/profile:#export PATH DISPLAY LESS TERM PS1 PS2
/etc/slrn.rc:% WWW browser to use. Xbrowser is used when the DISPLAY environment variable
/etc/termcap:######## LCD DISPLAYS
/etc/termcap:#	DISPLAY FUNCTION	GROUP III
/etc/termcap:#  This must be used with DISPLAY FUNCTION GROUP I or III


/etc/postfix/main.cf.default:import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY DISPLAY LANG=C POSTLOG_SERVICE POSTLOG_HOSTNAME
/etc/security/pam_env.conf:# Set the DISPLAY variable if it seems reasonable
/etc/security/pam_env.conf:#DISPLAY		DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}

>> grep DISPLAY /etc/rc.d/*
was empty. Did not find anything.

selfprogrammed · 09-11-2023, 10:09 AM

I have modified my dump by adding a date, and including the message from startxfce4, so I know which path it took.
Modified test again, putting a call to the dump into the "success" path, and one in the "fail" path.
This starts a x-windows session, in spite of failing the DISPLAY test.
What is weird, is I thought that the other user was running on "DISPLAY=:0".

Code:

====
Mon Sep 11 09:27:48 CDT 2023
DEBUG_DUMP: /usr/bin/startxfce4
/usr/bin/startxfce4: X server already running on display :1
DISPLAY=(:1)=
OPT param=
XFCE4_SESSION_WITH_CK=
SERVERRC=
CLIENTRC=
XDG_CONFIG_HOME=
BASEDIR=/home/user2/.config/xfce4/
XDG_DATA_DIRS=/usr/local/share:/usr/share
XDG_CONFIG_DIRS=/etc/xdg:/etc/kde/xdg:/etc/xdg
DISPLAY=:1
XDG_VTNR=7
END_LOG\n
Execute normal:  exec /bin/sh /etc/xdg/xfce4/xinitrc

selfprogrammed · 09-11-2023, 11:12 AM

I have tracked down the $DISPLAY, but not why it gets set wrong.
DISPLAY gets set by the /usr/bin/startx script.
According to the man page for startx, it is set and NEVER READ.

Startx determines DISPLAY from the following bit of script.

Code:

# Automatically determine an unused $DISPLAY
d=0
while true ; do
    [ -e "/tmp/.X$d-lock" -o -S "/tmp/.X11-unix/X$d" ] || break
    d=$(($d + 1))
done
defaultdisplay=":$d"
unset d

One of the arguments to startx can set the display.
The bad indenting here is in the original.

Code:

   *)
 if [ "$whoseargs" = "client" ]; then
     clientargs="$clientargs $1"
 else
     # display must be the FIRST server argument
     if [ x"$serverargs" = x ] && \
   expr "$1" : ':[0-9][0-9]*$' > /dev/null 2>&1; then
  display="$1"
     else
  serverargs="$serverargs $1"
     fi
 fi
 ;;

Finally:

Code:

# if no display, use default
if [ x"$display" = x ]; then
    display=$defaultdisplay
fi

Later it gets used:

Code:

    authdisplay=${display:-:0}

Conditionally, if enable_xauth then there are more complications, but I have not determined if that bit is even invoked.

At the top of this is this line

Code:

# Site administrators are STRONGLY urged to write nicer versions.

Does anyone know of anybody who writes their own "nicer" startx. What guidelines would they use.

So, it would seem that x-windows shutdown is leaving behind lock files.
/tmp/.X0-lock
/tmp/.X11-unix/X0

selfprogrammed · 09-22-2023, 05:55 PM

Update on progress:

The DISPLAY problem, is completely bogus.
I got the startx and startxfce4 scripts instrumented, so the next time the startx fails, I would have a log of what exactly happened.

It was when I also enabled saving logs from a successful startup (it is intermittent), that I noticed that it ALWAYS finds DISPLAY is already set, and ALWAYS puts out that message that X is already running.

Tracked it down to the startx script, which sets DISPLAY entirely according to lock files kept in /tmp.
Any other setting or clearing of DISPLAY would be irrelevant.
If there were not lock files already present, its next actions would create them.

The message is misleading, as it looks like an error message, but is not.

If the user executes startxfce4 directly, then it will discover that DISPLAY is not set, and that X needs to be started. So then it will execute xinit, which does that.

If the user executes startx directly, it starts X, and then executes the default window manager, which it starts using startxfce4.
The DISPLAY variable is just the communication between them.

The failing of startx, which I am experiencing, must then have something to do with the ICE messages which follow afterwards.
I have yet to diagnose those.
They are not getting recorded in any logs that I can find, yet, and I don't have any saved, yet.

As the this no longer has anything to do with DISPLAY, I am marking the original problem as solved, even though I still have the intermittent failure of startx.

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

I have found the cause of the problems, but should discuss how to fix on Slackware.
I have tried to post a thread for this but keep getting blocked by CloudFlare.
I have tried getting the thread moved, but am ignored on that. Total silence, I think the moderator is distracted or mad at me or something.

Please see https://www.linuxquestions.org/quest...tx-4175729610/

CloudFlare is blocking my posting. I do not know what it wants, it just sits there spinning.

mrmazda · 11-03-2023, 05:28 PM

Have you tried deleting linuxquestions.org cookies? What about adding it to, or removing it from, /etc/hosts? Cloudfare blocking hasn't happened here in at least a year. I have multiple browsers installed. When a site won't work in one, I try another.