CARTAvis / carta-backend

Source code repository for the backend component of CARTA, a new visualization tool designed for the ALMA, the VLA and the SKA pathfinders.
https://cartavis.github.io/
GNU General Public License v3.0
22 stars 11 forks source link

carta startup options are not available when running without an X display #382

Closed jott3077 closed 4 years ago

jott3077 commented 4 years ago

When trying to use carta --help or carta --remote etc., without an attempt to bring up the GUI in the first place, all startup options fail when there's no X display available.

The task startup should not require X when anything but a GUI is requested (including the launch of the "carta --remote" server)

Here's an example:

[jott@nmpost028:~]> carta --help

(process:14740): Gtk-WARNING **: 11:52:32.791: Locale not supported by C library. Using the fallback 'C' locale.

(carta:14740): Gtk-WARNING **: 11:52:32.792: cannot open display: [jott@nmpost028:~]>

similarly: [jott@nmpost028:~]> carta --remote

(process:15547): Gtk-WARNING **: 11:55:26.476: Locale not supported by C library. Using the fallback 'C' locale.

(carta:15547): Gtk-WARNING **: 11:55:26.478: cannot open display: [jott@nmpost028:~]>

does not launch the backend server and does not display the URL to connect to.

veggiesaurus commented 4 years ago

@ajm-asiaa what's the status of this issue?

ajm-ska commented 4 years ago

I investigated and tried to fix it, but unfortunately I feel it can not be done.

The whole "remote" mode idea was just patched in to the desktop version through the Electron startup script. It doesn't go as far as opening the Electron window on screen, however, it is still effectively starting Electron, and that is why it requires X11. So it still requires an X11 connection despite not showing/opening any window.

I was thinking that an alternative could be to have the real remote version's startup script in the package so that the user could start it using separate script. However, this would only be possible on the MacOS version because that is the only version where we have access to the package's file structure. For example, the user could run something like /Applications/CARTA.app/Contents/Resources/app/carta-backend/remote.sh (although I know that may not be completely intuitive). But the problem is the AppImage on Linux. In an AppImage, we don't have access to any files inside the package, and Linux is the only situation where you may want to start the desktop version on a headless remote server.

So I would suggest that in cases where there is no X-display on a system, to just use the real remote version, or if it is at an institute, get the system administrators to set up the server version.

But I am open to any ideas? @jott3077 @veggiesaurus

veggiesaurus commented 4 years ago

what about running a script before calling the electron startup script? If --remote is passed to the starter script, it doesn't run the electron startup script, but starts the backend directly?

ajm-ska commented 4 years ago

Thank you @veggiesaurus That might work for AppImages, which is all we need. I just tried it. I renamed the original AppRun executable as CARTA, and created a new bash script called AppRun to act as direct replacement containing the following:

#!/bin/bash

for arg in "$@"
do
    if [ "$arg" == "--remote" ]
     then
        echo "Pure remote mode requested"
        ./carta-remote.sh
     fi
    done

if [ $# -eq 0 ]; then
    echo "Starting normal mode"
    ./CARTA
fi

For now I just copied over the entire remote version into the directory, just to check if it works.

But now the problem is finding the correct path after it is packed back into the AppImage. The AppImage seems to be mounted and run from a randomly generated tmp directory, but the contents of the bash script are run from the directory where I execute the AppImage from.

./test.AppImage --remote
Pure remote mode requested
/tmp/.mount_test.A8llVi5/AppRun: line 12: /home/ajm/carta-remote.sh: No such file or directory

I also tried putting $PWD into the script and $APPIMAGE but they still think I mean the directory where I am executing the AppImage. I need some way to find that randomly generated tmp path... I'll try searching Google a bit more.

ajm-ska commented 4 years ago

@veggiesaurus I did it! It was easy in the end. I can simply use the same way that I figured out before for defining the correct path of the ephemerides and geodetic data directory for the carta-backend:

DIRNAME=`dirname $0`

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )"

Now it works!

ajm-ska commented 4 years ago

I believe I have it working now. If the "--remote" flag exists, it will start the remote mode script and conveniently pass all other flags to it, otherwise it will start the normal Electron version and pass all other flags to it. We also need another case if no arguments are passed at all. I think this is the simplest way to do it.

#!/bin/bash

DIRNAME=`dirname $0`
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )"

for arg in "$@"
do
    if [ "$arg" == "--remote" ]
     then
        echo "Remote mode requested"
        $DIR/carta-remote.sh $1 $2 $3 $4 $5 $6 $7
      else
        echo "Starting normal mode"
        $DIR/CARTA $1 $2 $3 $4 $5 $6 $7
     fi
done

if [ $# -eq 0 ]; then
    echo "Starting normal mode - no arguments provided"
        $DIR/CARTA
fi

I also modified the "help" readouts so that the help text from Electron's javascript file is identical to the remote mode's bash script help text. Although of course it will still give the X11 error if you try to do something like ./CARTA-v1.3 --help without X11 access. You would instead need to do ./CARTA-v1.3 --remote --help. Well I suppose that could be fixed by moving the help text to this new intermediate file script...

Anyway, for now I have uploaded the v1.3-alpha version with it to here. But I'll be sure to implement it into the v1.3-beta version, so maybe it would be better to wait until then to test it.

veggiesaurus commented 4 years ago

@ajm-asiaa can we close this?

ajm-ska commented 4 years ago

Yes. I believe we can. The issue has been solved.