Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: gwalther on December 08, 2010, 03:58:20 PM
-
I booted with tinycore 3.3 and boot codes... base norestore.
I then download and load the extensions graphics2.6.33-tinycore and Xorg-7.5.
After the Xorg downlaod and load I can no longer use the exit option...exit to prompt.
Nothing happens when I try to... exit to prompt.
I am able to select reboot and it works.
Am I missing something?
-
I run into something similar when I boot into the regular system (xvesa) then open a terinal window and load Xorg-7.5.tcz then try to exit to prompt so I can use startx to come back into X using Xorg. The exit-to-prompt does not work. However if I Ctrl-ALlt-Backspace it drops me out of X and startx will do the right thing. I just assumed I was breaking something minor by not exiting to the prompt before loading Xorg-7.5.
I'm using micro core 3.3 w/core elements, wbar and jwm. Booting from the same usb stick on several different systems. Anything with a 16:9 monitor needs Xorg to avoid stretching. Some need graphics-2.6.33.3-tinycore while others do not.
-
I was doing the same thing you were....boot regular system (Xvesa)...load Xorg and then trying to exit to prompt so I could run Xorg -configure and edit xorg.conf per instruction in ...Info...and then restart..but "exit to prompt" would not work.
Tried same thing on another machine....same result.
Started to think maybe I had a bad download/burn...but if you saw same thing then maybe not.
Did a killall Xvesa to get to prompt...did the Xorg stuff and edit..then startx..it worked but now the Exit icon did not work at all and if I tried ...exittc ...from a terminal I got a segmentation fault...????
-
This has been discussed before; exittc tries to kill the currently-configured X server, which is Xorg after that extension is loaded.
Known bug/feature, patches welcome if it bugs you enough ;)
-
Makes sense, same would happen to me after loading Xvesa.tcz, no Xorg involved.
-
what about changing:
if (action == 3) {
system("sudo pkill `cat /etc/sysconfig/Xserver` &");
exit(0);
} else {
to something like: if (action == 3) {
system("sudo pkill `/bin/ps -o args | /usr/bin/cut -d " " -d 1 | /bin/grep "^X\|^/usr/local/bin/X"` &");
exit(0);
} else {
should work for Xvesa, Xorg, X, Xfbdev, Xvnc...
Edit:
Or: if (action == 3) {
system("sudo pkill `/bin/ps -o args | /usr/bin/awk '/(^X)|(^\/usr\/local\/bin\/X)/ {print $1}'` &");
exit(0);
} else {
-
Hmmm, whilst the suggestion in reply #5 might be an improvement to the current state I feel a bit uneasy of this criteria to kill all processes with names starting with 'X' or '/usr/local/bin/X' as there are a few "bystanders" that would also get "hit" (e.g. 'Xwrapper', 'Xdialog', 'Xnest', 'Xephyr', and 'Xdmx').
Now granted for the vast majority of cases (when just running a single X server) those clients should anyway not "survive" the termination of the Xserver. But I wonder whether an alternative would be to record the X server PID in a file (via adding for example echo $! | sudo tee /var/run/Xserver.${DISPLAY}.pid as a second line to '/etc/skel/.xsession') in which case that information could then be used to kill one particular X server. As I envisage that a bit more "cleanup" work would be required I'd suggest to create a little script (lets call it e.g. 'termx' or 'exitx') along the lines of:
#/bin/sh
PID_FILE="/var/run/Xserver.${DISPLAY}.pid"
if [ -f $PID_FILE ] ; then
sudo kill $( cat $PID_FILE )
sudo rm -f $PID_FILE
else
/bin/ps -o 'pid,args' \
| grep -E '^ *[0-9][0-9]* (|[^ ][^ ]*/bin/)X(vesa|org|fbdev|vnx)' \
| awk '{ print $1 }' | xargs -p 1 | sudo kill
fi
As you can see I've included also a "sledgehammer" branch but with an attempt to narrow it down a bit further. This script could then be called from 'exittc' and would allow for easier adjustments in the furture.
(WARNING: the code snippet was not really tested)
-
Over the night I thought of "sudo fuser -k /tmp/.X11-unix/X0", or maybe something based on "sudo netstat -lxp".
What do you think?
@robc: I agree with maro, there's the bystanders issue. One may have Xvnc or the like running that should not be killed at that point.
@maro: no X server name should be hard-coded there IMO.
-
Hmmm, whilst the suggestion in reply #5 might be an improvement to the current state I feel a bit uneasy of this criteria to kill all processes with names starting with 'X' or '/usr/local/bin/X' as there are a few "bystanders" that would also get "hit" (e.g. 'Xwrapper', 'Xdialog', 'Xnest', 'Xephyr', and 'Xdmx').
There is also a possibility a user may run more than one instance of the same X server.
-
Over the night I thought of "sudo fuser -k /tmp/.X11-unix/X0"
sounds simple - but... "sudo fuser /tmp/.X11-unix/X0" (omitting the '-k') does not render any output on my system, as I have noted with 'fuser' in other cases as well (not TC particular).
-
The title of this thread is very misleading as this is much to do about a one time event (loading an X server while running an X server).
"exit to prompt" works fine from Xorg or any X server under normal conditions.
This is being posted using Xorg while fully being able to "exit to prompt" ::)
-
I would suggest, if this one time event is such an annoyance, that the extension's startup script be adjusted to check if X is already running. If so, do not overwrite the current X server, Instead, exit.
This would have no impact on normal operations, .i.e, from booting or loading X while not currently running X.
Additionally a link to the startup script could be placed in the user's path together with a note in the .info file for such manual X server initialization. Such would not be much different than other distributions requiring some X server setup before initial run. Such would only be required when an alternate X server is loaded from within an already initialized and running X server.
When the base fully supports normal operations, then the base should be preserved and not cluttered with extension references or requiring needless extra code.
-
Been there many times and it never bothered me much.
If any change would be attempted which would not be 100% guaranteed free from potential side effect under every possible constellation, I'd rather prefer to see some additional button like e.g. Force exit to prompt than to do away with current.
-
I have modified exittc to use the PID of the running X.
This should satisfy both goals of no extra code, no extension references and no mods required to existing X server extensions.
-
Geee, that was rather foolish of me to suggest to "re-invent the wheel": I'd forgotten to take a look into '/tmp/.X*-lock'. As it turns out this very file already contains the PID of the respective X server. I therefore believe now that there might not be a need to save the information in a convoluted way (as I had suggested in reply #6).
I noticed this 24h ago, but I've been "sitting on this information" as I wanted to test it in a specific way. As I've just noticed that Robert has put out a second version of TC 3.4rc2 which changes '.xsession' to save the PID of the X server via an environment variable. I now believe that using sudo kill $( cat /tmp/.X${DISPLAY:1:1}-lock ) in 'exittc' would achieve the same, without the need of changing '/etc/skel/.xsession'.
NOTE: This was not as well tested as I liked, but might still be worth a consideration.
-
I'll buy that. 8)