Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: GNUser on November 10, 2022, 10:30:28 AM
-
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:
#!/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?
-
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.
echo "$(date): Restarting X" >> $log
-
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.
-
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:
# 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.
-
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/
-
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.
-
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.
env > filebeforestartx.txt
If i remember correct the startx is also some script to set some env variables before executing the elf binary.
startx
Start some term in x and execute.
env > fileafterstartx.txt
And then diff the files.
diff filebeforestartx.txt fileafterstartx.txt
Happy hacking free open source software. :)
-
Hi, patrikg. Thanks for the help. Here you go:
$ 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:
#!/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
-
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.
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.
echo -e "User: $USER\nUsername: $USERNAME" >> scriptusername.txt
-
Here is the output of env | sort in the virtual terminal/console (i.e., an environment where startx works):
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):
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.
-
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:
#!/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.
-
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
su - bruno -c 'startx'
in the script.
And maybe...
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
su bruno -c 'env'
And
su - bruno -c 'env'
-
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...
-
Your another script run as user bruno or what??
-
Sorry to say, but i taking this from air... just messing around, try to think what your problem is.
But thanks for the thanks :)
-
The script runs as regular user, which is bruno in my case (I use the user=bruno bootcode).
I don't have a problem per se. Just trying to solve the mystery of why this particular script doesn't work as expected unless it is launched while X is not running. I don't like mysteries of this kind.
-
Hi GNUser
I believe $HOME/.profile gets run when that user gets logged in.
Startx is is just a script that looks at and sets up a bunch of variables.
less -I `which startx`
It exits if it can't locate a desktop to use.
At the end, it runs:
exec $HOME/.xsessionWhich starts Xorg/Xvesa, loads the desktop, and runs the contents of $HOME/.X.d.
-
Thanks, Rich. I tried changing startx to exec $HOME/.xsession and script still only works if launched when X is not running. Very strange.
I'm sorry I bothered you guys with this. I guess this one will remain a mystery.
-
Thx @Rich, for your support.
OK, Bruno, with the boot code user=bruno, i think there some of the boot scripts runs as root because they need to do so.
So you have to se what user runs your script ??
You can verify that with like i said in previous thread.
You have to add one more line to your script file :)
-
Maybe the issue is that startx has to be launched from an interactive login shell in order to work. If I ever figure it out I'll post something here.
Thanks guys, but I'm giving up on this for now.
-
i used @Rich "less -I `which startx`" on devuan beowulf and compared it to a CorePlus-13x LiveCD booted into just the basic GUI startx and the devuan beowulf is different/larger/more-commented(naturally)
see attached file for startx from devuan beowulf(NOTE:no-systemd/non-systemd/whichever-you-prefer!)
in this version of startx there is a link to:
https://bugzilla.redhat.com/show_bug.cgi?id=806491
and i also did a search using google with a cut-and-paste from the beginning comment of the devuan beowulf startx script:https://www.google.com/search?q=%23+This+is+just+a+sample+implementation+of+a+slightly+less+primitive+%23+interface+than+xinit.+It+looks+for+user+.xinitrc+and+.xserverrc+%23+files%2C+then+system+xinitrc+and+xserverrc+files%2C+else+lets+xinit+choose+%23+its+default.+The+system+xinitrc+should+probably+do+things+like+check+%23+for+.Xresources+files+and+merge+them+in%2C+start+up+a+window+manager%2C+%23+and+pop+a+clock+and+several+xterms.&oq=&aqs=
with many results(naturally)...so scrolled through results on first page and went to:
https://forums.bunsenlabs.org/viewtopic.php?id=4647
which may or may-not be of assistance/help/etc
PLEASE NOTE: both provided URLs link to distros that ARE currently using SYSTEMD(just-an-fyi/reminder/footnote)
also note that "ls -ahlrt" while working in your home directory(tcl-default=/home/tc) shows output in reverse-order-based-on-time(so newest/last-written-to/etc at the bottom of the list)
20221112-0538am-cdt-usa-modified: just wanted to add that that redhat bug report was created/started in 2012...so this is NOT a new bug/curiosity/mystery/question...
-
Hi, Rich. I know you are a wizard. If you have the time and interest, can you help me tweak this simple script so that it works?
#!/bin/sh
pkill Xorg
sleep 3
startxExpected behavior after launching this script from a terminal emulator (e.g., aterm or xterm) is this:
1. user's desktop disappears
2. console shows up for 3 seconds
3. user's desktop reappears
Actual behavior is this:
1. user's desktop disappears
2. console shows up
3. user's desktop does not reappear (user must type startx at the console's command prompt for desktop to reappear)
I'm asking for help because I've already scoured the internet and tried too many things to enumerate.
-
Hi GNUser
I got this to work. I created a script called RestartX:
#!/bin/sh
pkill Xorg
sleep 3
sudo openvt -c 1 -s login -f tc
Then launched it like this:
./RestartX &
-
When xterm dies, it may take the script with it. That kills the terminal it was running in, and it has no more input or output. nohup is used to work around that, but it'd be better to launch it from somewhere else.
-
did a little browsing and found this thread interesting(perhaps moreso for our future readers):
https://stackoverflow.com/questions/15595374/whats-the-difference-between-nohup-and-ampersand
another link for reference(but one of the answers/replies refers back to the above thread):
https://stackoverflow.com/questions/40614243/nohup-does-not-work-properly
20221116-0222am-cdt-usa-modified-added additional link
-
Thank you, Rich. Wow, it works exactly as expected.
For those of you who don't know what Rich looks like in person, here is a recent portrait:
(http://forum.tinycorelinux.net/index.php?action=dlattach;topic=25999.0;attach=6310)
-
Hi curaga
When xterm dies, it may take the script with it. ...
The script can be launched from a terminal or through .X.d.
I launched the following test script in the background from pts/7:
#!/bin/sh
while true
do
sleep 1
pgrep Xorg > /dev/null || break
doneAs long as pgrep finds Xorg, it will keep on running.
Then from another terminal:
tc@E310:~$ tty
/dev/pts/9
tc@E310:~$ ps -Af | grep './test' | grep -v grep
tc 10517 9258 0 09:59 pts/7 00:00:00 /bin/sh ./testThe program is running on pts/7 which has a PID of 9258.
tc@E310:~$ sudo kill -9 9258
tc@E310:~$ ps -Af | grep './test' | grep -v grep
tc 10517 1 0 09:59 ? 00:00:00 /bin/sh ./test
tc@E310:~$The terminal was killed, but the script was just re-parented to PID 1
with no tty listed.
If tty1 dies, it should respawn via inittab and present a login prompt
on the console.
-
Hi, Rich. When your script restarts X, it leaves this message in the console: "-sh: can't access tty; job control turned off". I don't think there is a real problem because everything works fine within the restarted X session.
Do you know what the message means? And how do we make it not show up? I tried adding 2>/dev/null to various places but the message still shows up.
-
Hello again, Rich. If you have any insights about the error message, great. If not, no worries. You've already helped me enough with this.
Topic may be marked as Solved :)
-
Hi GNUser
I had the same message showing up. I only did a brief search
on that, so short answer suggests consoles do not handle job
control and the message is just informational.
... Here is my x-watchdog script:
#!/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 second true statement doesn't do anything. while true will run
forever unless a break statement is encountered.
Just a little simplification:
#!/bin/sh
log=$HOME/log.txt
while true
do
sleep 10
# This loops every 10 seconds as long as Xorg is found.
pgrep Xorg > /dev/null && continue
# We drop through to here when Xorg is not found.
echo "Restarting X" >>$log
sudo openvt -c 1 -s login -f tc
doneOr in your case, I suspect the user is bruno , not tc.
-
Hi GNUser
I had the same message showing up. I only did a brief search
on that, so short answer suggests consoles do not handle job
control and the message is just informational.
Thanks for confirming that you also get the message, and that you also favor that it is merely informational.
I had already edited my x-watchdog script, replacing startx with sudo openvt -c 1 -s login -f bruno and now I can launch it from ~/X.d/ along with all my other startup jobs, thanks to you. The script works exactly as intended. Once again, many thanks! :)
-
P.S. This is the openvt command's help:
$ openvt --help
BusyBox v1.34.1 (2022-04-30 13:49:24 UTC) multi-call binary.
Usage: openvt [-c N] [-sw] [PROG ARGS]
Start PROG on a new virtual terminal
-c N Use specified VT
-s Switch to the VT
-w Wait for PROG to exit
One odd thing is that the -c 1 flag causes X to be restarted in tty2. If I change the flag to -c 2 then X is restarted in tty3. I don't quite understand this. Oh, well. It seems that starting/restarting X is fraught with unexpected things.
-
ftr & out of curiocity ( https://busybox.busybox.narkive.com/Y0331j2s/new-applet-openvt )
this is appears to be the latest the bb openvt source : https://git.busybox.net/busybox/tree/console-tools/openvt.c?h=1_35_stable
this https://git.busybox.net/busybox/commit/?h=1_34_stable *should*
match the version used in http://tinycorelinux.net/13.x/x86_64/release/src/busybox/ 13.1 x86_64
minus the patches :P
the function find_free_vtno appears to handle the '-c' case
which mentions ( though im not shore how relevent that may or may not be tbh =s )
// Not really needed, grep for DAEMON_ONLY_SANITIZE
https://git.busybox.net/busybox/tree/console-tools/openvt.c?h=1_35_stable#n156
also ... some intresting discution @ http://lists.busybox.net/pipermail/busybox/2009-December/071170.html
which mentions/quotes from "See docs/ctty.htm, "Getting a controlling tty":" which i found an old copy of in this link http://bls.buu.ac.th/~s54326/08Dec16/busybox-1.19.3/docs/ctty.htm
also on this tangent iv found https://landley.net/notes-2011.html#28-08-2011 - "(Did I mention I spent several weeks, some time back, setting everything up so that ctrl-c would exit an aboriginal linux native build? This involved getting a controlling TTY which /dev/console isn't, moving the shell off of PID 1 which has most signals blocked so it would ignore ctrl-c anyway, and then calling shutdown() to exit the emulator. It's sources/toys/oneit.c and sbin/init.sh setting it up, and together they make it look like I didn't do anything because it just works.)"
all though im not shore how relevnt all that may or many not be !
-
I found an alternative solution. Script can be named RestartX as before, with this in it:
#!/bin/sh
pkill Xorg
sleep 1
sudo setsid sh -c "exec login -f $(whoami) <>/dev/tty3 >&0 2>&1"
The script can be run from a terminal emulator running within X like so:
./RestartX &
This solution is based on this idea: https://unix.stackexchange.com/a/170075
-
Sorry to spam the thread, but I wanted to share that this slightly simpler version works just as well:
#!/bin/sh
pkill Xorg
sleep 1
sudo sh -c "login -f $(whoami) <>/dev/tty3 >&0" &
-
From first post in this thread:
On my media player, X crashes once in a while. I'm not sure why
A quick follow-up in case this information is helpful to someone: It turns out that all the crashes happen when watching a video in Brave (extension from repo) or Chrome (.deb -> homebrewed .tcz) in fullscreen mode. It doesn't happen every time, only once in a great while. Unfortunately, /var/log/Xorg.0.log shows nothing helpful, just a segfault. mpv in fullscreen mode, on the other hand, never causes a crash.
The media player is now running TCL14-alpha 64-bit rather than TCL13.1 64-bit. The TCL version makes no difference.
I don't think there is anything to be done about it. Just something to be aware of, I guess.