Xorg and "Exit to prompt"

[gwalther]

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?

[Lee]

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.

[gwalther]

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...?

[curaga]

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

[tinypoodle]

Makes sense, same would happen to me after loading Xvesa.tcz, no Xorg involved.

[robc]

what about changing:

Code: [Select]

 if (action == 3) {
     system("sudo pkill `cat /etc/sysconfig/Xserver` &");
     exit(0);
  } else {
to something like:

Code: [Select]

 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:

Code: [Select]

 if (action == 3) {
     system("sudo pkill `/bin/ps -o args | /usr/bin/awk '/(^X)|(^\/usr\/local\/bin\/X)/ {print $1}'` &");
     exit(0);
  } else {

[maro]

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:

Code: [Select]

#/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)

[curaga]

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.

[tinypoodle]

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.

[tinypoodle]

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).

[roberts]

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" 

[roberts]

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.

[tinypoodle]

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.

[roberts]

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.

[maro]

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.