[Solved]: why doesn't startx work from within a shell script?

[GNUser]

All my machines run TCL13.1 x86_64 with Xorg-7.7. My X session and window manager (fluxbox) start automatically on boot on all of them.

On my media player, X crashes once in a while. I'm not sure why, but it would be simpler to create a watchdog-type script that restarts X when it crashes than it would be to troubleshoot.

Here is my  x-watchdog  script:

Code: [Select]

#!/bin/sh

log=$HOME/log.txt

while true; do
if pgrep Xorg >/dev/null; then
true
else
echo "Restarting X" >>$log
startx
fi
sleep 10
done

The script is launched at boot as regular user and runs continuously in the background. To test the script, I intentionally stop X by running pkill Xorg, which causes a virtual terminal to show up as expected. I then wait 10 seconds or more. The log shows "Restarting X" but X does not restart as expected; the startx in the script seems to have no effect

If I manually run startx at the console, then it works just fine (i.e., X and my WM start as expected).

Why does the startx in the script have no effect? Does anyone know how to fix the script so that startx works?

[patrikg]

If you look at the files that spawns then running the shell like .bashrc i think there something there to set the correct tty when running X.
Maybe when running startx don't run this script and don't set the correct tty.

And may I suggest to add date/time to the script when logging.
Something like this.

Code: (bash) [Select]

echo "$(date): Restarting X" >> $log


[GNUser]

It must have something to do with script's environment. If script is launched from console when X is not running, then script's startx works. If script is launched from a terminal emulator within a running X session, then script's startx doesn't work.

I'm comparing the two environments (virtual console vs. terminal emulator within X) to try to pinpoint the issue.

[GNUser]

I can't crack this one. A very specific environment seems to be required for startx to work in a shell script.

If I start the x-watchdog script from bootlocal.sh or bootsync.sh, then the script's startx doesn't work as expected (my WM customizations are missing).

If I start the x-watchdog script from ~/.X.d then the script's startx doesn't do anything at all.

It seems that it's only when the script is launched from near the end of ~/.profile that it works as intended. These are now the last few lines of my ~/.profile:

Code: [Select]

# I added this line:
x-watchdog &

# These lines were already there:
TERMTYPE=`/usr/bin/tty`
[ ${TERMTYPE:5:3} == "tty" ] && (
[ ! -f /etc/sysconfig/Xserver ] ||
[ -f /etc/sysconfig/text ] ||
[ -e /tmp/.X11-unix/X0 ] ||
startx
)

I figured it would probably work there because, as you can see from the penultimate line, that's where startx is normally launched from.

P.S. Even though the script works as intended now, I feel defeated in that I cannot pinpoint why the script can only be launched from ~/.profile and not from bootlocal.sh, bootsync.sh or ~/.X.d. If anyone knows the secret sauce that needs to be added to the script so that it can be launched from anywhere, please do tell.

[gadget42]

went poking around and came across this thread which might shed some light on your situation

https://www.linuxquestions.org/questions/slackware-14/run-startx-from-script-4175616930/

[GNUser]

Hi, gadget42. Thank you for that. I tried sh startx and exec startx but neither one helps make script work when launched from outside of ~/.profile.

At least on TCL, there seems to be something unique about the environment at that point in the boot process (i.e., user has just logged in, ~/.profile is being parsed, X has not yet started) that is required for startx to work.

[patrikg]

Why not just try to insert the termtype lines into your script.
-----
It execute the tty command and set the env variable to that and then cut
some chars of that string.
-----
Before your startx line.

And you can also run command env to se all env variables and save to file, and diff that.

Code: (bash) [Select]

env > filebeforestartx.txt


If i remember correct the startx is also some script to set some env variables before executing the elf binary.
 

Code: (bash) [Select]

startx
Start some term in x and execute.

Code: (bash) [Select]

env > fileafterstartx.txt
And then diff the files.

Code: (bash) [Select]

diff filebeforestartx.txt fileafterstartx.txt
Happy hacking free open source software.

[GNUser]

Hi, patrikg. Thanks for the help. Here you go:

Code: [Select]

$ diff filebeforestartx.txt fileafterstartx.txt
--- filebeforestartx.txt
+++ fileafterstartx.txt
@@ -1,5 +1,9 @@
 BACKUP=1
-EDITOR=vi
+COLORFGBG=15;default
+COLORTERM=rxvt
+DESKTOP=fluxbox
+DISPLAY=:0.0
+EDITOR=editor
 ENV=/home/bruno/.ashrc
 FLWM_TITLEBAR_COLOR=58:7D:AA
 G_FILENAME_ENCODING=@locale
@@ -14,7 +18,11 @@
 PS1=${GREEN}\u@\h${WHITE}:${BLUE}\w${WHITE}\$
 PWD=/home/bruno/Downloads
 SHELL=/bin/sh
-SHLVL=1
-TERM=linux
+SHLVL=9
+TERM=rxvt-unicode-256color
 TZ=EST+5EDT,M3.2.0/2,M11.1.0/2
 USER=bruno
+WINDOWID=18874374
+WM_PID=11046
+XAUTHORITY=/home/bruno/.Xauthority
+XPID=11041
I tried tweaking script's environmental variables a bit as below, but startx still doesn't work if I launch the script from a terminal emulator:

Code: [Select]

#!/bin/sh

export TERMTYPE=/dev/tty1
export TERM=linux
export ENV=/home/bruno/.ashrc
export SHLVL=1
unset DISPLAY
unset XAUTHORITY
unset XPID

while true; do
if pgrep -f Xorg >/dev/null; then
true
else
echo "$(date): Restarting X" >$HOME/log.txt
startx
fi
sleep 10
done


[patrikg]

Sorry i forgot to say that you also need to see the env variable you have to add the line
before the startx command in your script.

Code: (bash) [Select]

env > inthescript.txt
to se what env variables is set in that scope.

Because i think it inherits the env variables from the parent process.

Then i think more of the problem ?? isn't it like what user run what script ??
bootlocal and so on runs with root i think and that runs your script as root as well.
Why not try just to echo out the user to file, to determine what user runs what ??

Append this also this line to your script.

Code: (bash) [Select]

echo -e "User: $USER\nUsername: $USERNAME" >> scriptusername.txt

[GNUser]

Here is the output of env | sort in the virtual terminal/console (i.e., an environment where startx works):

Code: [Select]

BACKUP=1
EDITOR=vi
ENV=/home/bruno/.ashrc
FLWM_TITLEBAR_COLOR=58:7D:AA
G_FILENAME_ENCODING=@locale
HOME=/home/bruno
LANG=en_US.UTF-8
LOGNAME=bruno
MANPAGER=less -isR
NO_AT_BRIDGE=1
OLDPWD=/var/log
PAGER=less -EM
PATH=/opt/scripts:/opt/bin:/home/bruno/.local/bin:/usr/local/sbin:/usr/local/bin:/apps/bin:/usr/sbin:/usr/bin:/sbin:/bin:/etc/sysconfig/tcedir/ondemand
PS1=${GREEN}\u@\h${WHITE}:${BLUE}\w${WHITE}\$
PWD=/home/bruno/Downloads
SHELL=/bin/sh
SHLVL=1
TERM=linux
TZ=EST+5EDT,M3.2.0/2,M11.1.0/2
USER=bruno
Here's the output of env | sort in my script (i.e., an environment where startx doesn't work):

Code: [Select]

BACKUP=1
COLORFGBG=15;default
COLORTERM=rxvt
DESKTOP=fluxbox
DISPLAY=:0.0
EDITOR=editor
ENV=/home/bruno/.ashrc
FLWM_TITLEBAR_COLOR=58:7D:AA
G_FILENAME_ENCODING=@locale
HOME=/home/bruno
LANG=en_US.UTF-8
LOGNAME=bruno
MANPAGER=less -isR
NO_AT_BRIDGE=1
OLDPWD=/var/log
PAGER=less -EM
PATH=/opt/scripts:/opt/bin:/home/bruno/.local/bin:/usr/local/sbin:/usr/local/bin:/apps/bin:/usr/sbin:/usr/bin:/sbin:/bin:/etc/sysconfig/tcedir/ondemand
PS1=${GREEN}\u@\h${WHITE}:${BLUE}\w${WHITE}\$
PWD=/home/bruno/Downloads
SHELL=/bin/sh
SHLVL=16
TERM=rxvt-unicode-256color
TERMTYPE=/dev/tty1
TZ=EST+5EDT,M3.2.0/2,M11.1.0/2
USER=bruno
WINDOWID=16777222
WM_PID=11073
XAUTHORITY=/home/bruno/.Xauthority
XPID=10392After seeing the above, I tried adding unset DISPLAY and export TERM=linux and unset TERMTYPE to top of script but it didn't help.

[GNUser]

Hi, patrikg. It seems the relevant environment characteristic is not something that's being shown by the env command. Even if I replicate the virtual terminal/console's environment based on env's output exactly, like this:

Code: [Select]

#!/bin/sh

export BACKUP=1
export EDITOR=vi
export ENV=/home/bruno/.ashrc
export FLWM_TITLEBAR_COLOR=58:7D:AA
export G_FILENAME_ENCODING=@locale
export HOME=/home/bruno
export LANG=en_US.UTF-8
export LOGNAME=bruno
export MANPAGER="less -isR"
export NO_AT_BRIDGE=1
export OLDPWD=/var/log
export PAGER="less -EM"
export PATH=/opt/scripts:/opt/bin:/home/bruno/.local/bin:/usr/local/sbin:/usr/local/bin:/apps/bin:/usr/sbin:/usr/bin:/sbin:/bin:/etc/sysconfig/tcedir/ondemand
export PS1=${GREEN}\u@\h${WHITE}:${BLUE}\w${WHITE}\$
export PWD=/home/bruno/Downloads
export SHELL=/bin/sh
export SHLVL=1
export TERM=linux
export TZ=EST+5EDT,M3.2.0/2,M11.1.0/2
export USER=bruno

unset COLORFGBG
unset COLORTERM
unset DESKTOP
unset DISPLAY
unset WINDOWID
unset WM_PID
unset XAUTHORITY
unset TERMTYPE

while true; do
if pgrep -f Xorg >/dev/null; then
true
else
echo "$(date): Restarting X" >$HOME/Downloads/log.txt
startx
fi
sleep 10
done

startx still doesn't work if I launch the above script from within an X session.

It seems only someone with intimate knowledge of Xorg's baroque innards would be able to pinpoint what's special about the virtual terminal/console environment that is required for startx to work.

[patrikg]

Se my edited thread above.
And my Unix/Linux knowledge end there, if you can run the programs as another user.
Like sudo, that runs programs as user root.
If you can do something like

Code: (bash) [Select]

su - bruno -c 'startx'
in the script.
And maybe...

Code: (bash) [Select]

su bruno -c 'startx'

The dash inherit the parent env variables and sets some new ones and not spawns only new ones. You can se that with

Code: (bash) [Select]

su bruno -c 'env'
And

Code: (bash) [Select]

su - bruno -c 'env'

[GNUser]

Thanks for your help.

I'm just going to launch my script from within ~/.profile as I mentioned in reply #3.

But it really bugs me that I don't understand why I cannot launch the script from ~/.X.d/ like I do all my other startup jobs...

[patrikg]

Your another script run as user bruno or what??

[patrikg]

Sorry to say, but i taking this from air... just messing around, try to think what your problem is.
But thanks for the thanks