Running a user program on boot

Hi, I dont have much experience with Ubuntu and Jetson TX2. I’m using Jetson TX2 with:

  • L4T 28.2.0
  • Ubuntu 16.04.5 LTS
  • Kernel Version 4.4.38-tegra
  • CUDA 9.0.252
  • I have made a program in C++ with OpenCV that acces a GPIO PIN of the J26 Header and flash a LED several times. This programs works and I added to /etc/rc.local the following line to execute on boot of the Jetson:

    sudo /home/nvidia/UsingGPIOPortsExample/TestGPIO

    I shut down the Jetson, power up and LED flash several times during the boot sequence, so it works.
    Here is my doubt:
    I have another OpenCV program which uses the GPU and on-board camera to detect lines on the floor. When a line is present a LED goes ON, if not, goes OFF. The program displays a window too with the video recorded for the camera. This display is not needed is just for debugging so I can eliminate it.

    Will this program without the display run in the boot sequence as the other I explain before adding the simply line to /etc/rc.local?:

    sudo /home/nvidia/OpenCVExample/DetectLineGPIO

    Is this so simple or I am missing something cause i think it won’t work. I see in other topics something about a DISPLAY variable that i don’t understand at all.

    Thanks for help!

    OpenCV and many CUDA programs require an X11 context. I am guessing that you will need a virtual X server running under the same user as the program will run as, and then the “DISPLAY” set to the correct name (if there is a single X instance, then this would normally be “:0”, but for a virtual server it might be something like “:10”).

    GPU access typically requires more than command line. People often think of X11 as just the GUI or desktop, but at a lower level it is a buffer with a defined way of accessing it. It doesn’t matter if there is a monitor connected unless the monitor is how the buffer setup is determined. A virtual server has no monitor, but it does have a buffer the GPU understands.

    Thanks for your answer linuxdev.

    Now I understand a little bit more how to proceed. I have installed a Xvfb server on my Jetson’s Ubuntu with this command:

    sudo apt-get install xvfb

    Based on your answer, the next thing i have to do is start that server on boot before my application starts. Am I right?

    That can be done adding the correct command in the /etc/rc.local before the line on which my application starts? Something like this:

    sudo command that-starts-the-server -Xvfb
    sudo /home/nvidia/OpenCVExample/DetectLineGPIO

    While I wait for a response I will learn more about the server usage.

    Thanks for your help!

    I can’t give you the specific details for your case, but so long as the xvfb uses the NVIDIA GPU driver and you have set DISPLAY (each X server has a DISPLAY associated…the first local server is “:0”, the second local server is “:1”, so on…or it might be custom set to something like “:10”) and the xvfb is running under the same user name as the app will run, then this should be correct. Example:

    DISPLAY=:0 /some/command

    FYI, rc.local normally runs as root. You might need to use sudo to become a different user (“sudo” can be used with arguments, by root, to become non-root) when starting xvfb, and then use sudo to start your command as that other user. If everything is already intended to run as root, then you don’t have to worry about using sudo within rc.local.

    Thank you for the information. The thing is that yesterday I found this script on github, that have the structure of the scripts that executes on boot inside de directory /etc/init.d. The script was this:

    # Provides: Xvfb
    # Required-Start: $local_fs $remote_fs
    # Required-Stop:
    # X-Start-Before:
    # Default-Start: 2 3 4 5
    # Default-Stop: 0 1 6
    # Short-Description: Loads X Virtual Frame Buffer
    XVFBARGS=":1 -screen 0 1024x768x24 -ac +extension GLX +render -noreset"
    case "$1" in
        echo -n "Starting virtual X frame buffer: Xvfb"
        start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile --background --exec $XVFB -- $XVFBARGS
        echo "."
        echo -n "Stopping virtual X frame buffer: Xvfb"
        start-stop-daemon --stop --quiet --pidfile $PIDFILE
        echo "."
        $0 stop
        $0 start
            echo "Usage: /etc/init.d/xvfb {start|stop|restart}"
            exit 1
    exit 0

    So I download it, give it execution permission and place it inside de /etc/init.d directory with the rest of the scripts and ran this command:

    sudo update-rc.d xvfb defaults

    My intention was to boot the Jetson and then see if it the process was running with the htop command.

    So I boot the Jetson and for my surprise the creen of the monitor remains black all the time, I couldnt log-in and either kill that process to restore the image. I try to connect via ssh with other ubuntu PC, but no luck for me, so I ended flashing the Jetson…

    Do you know why I dont see nothing in the monitor with this script?

    After that i thought this: what if make a boot script that waits for 2 or 1 during the boot of Jetson, and then it executes the command that runs my app when the Jetson has completely boot (log-in screen appears). Will that work?

    And another question: Can I make that ubuntu skips the log-in screen and shows the desktop directly?

    Thank you for your help.

    There are a number of possibilities. It is difficult to say anything specific. If you have a serial console you should be able to see what is going on, and perhaps fix without flashing. If you do end up with a failure and cannot get access, then perhaps cloning could be performed to see what logs show.

    If you start this server manually on command line without sudo, does it look like the virtual server is working?

    If you start this server manually on command line with sudo, does it look like the virtual server is working?

    When you start X manually on command line there is no login screen. The way the automatic startup scripts work (this isn’t part of X, it is part of init scripts) is to run X with X itself running a login/display manager (X does not provide a desktop environment…X can only run one application…the window manager is a special application since this can run other applications…but so far as X is concerned it is only running one application). Login results in X respawning with the window manager as the argument (and sudo as a different user…whatever the login manager sees for login credentials) instead of the login/display manager.

    A typical failure where the screen goes black would not cause failure of ssh or physical console. A typical black screen failure might still illustrate part of what goes on…

    If an X server is purely in software, and not hardware accelerated, then it is unlikely to ever bring down the system even if misconfigured. When direct hardware access is involved, then a failure would show up within the driver, and the driver is usually running in kernel space. NVIDIA provides an OpenGL library which pairs with its X driver. If you were to replace the NVIDIA version of the OpenGL library with the Mesa version, then X will crash and burn since the NVIDIA driver was not linked against the Mesa OpenGL library. Any attempt to start X this way would either result in a crash or an infinite cycle of starting X, X failing, and then trying again to start X. One can run “sha1sum -c /etc/nv_tegra_release” to verify if the correct NVIDIA version of various files are valid.

    The NVIDIA driver must be used if GPU acceleration is required. The NVIDIA driver is linked against only a specific X ABI version. Using a newer or older X server with a different ABI would cause a crash even if the OpenGL library is the NVIDIA-provided version.

    If your Xvfb is not the same ABI as the installed X server, then crash would occur.

    If your Xvfb works with the NVIDIA driver, but references a Mesa version of the OpenGL library, then crash would occur.

    Some init scripts can be considered “optional” due to the way they are configured. For example, one can make a valid ethernet connection optional…if not, then lack of networking would prevent boot. An init script can make a boot configuration mandatory, e.g., accessing the hard disk and mounting a particular partition as “/” would never be optional (well…there may be odd cases of this being optional, but it is not “common”). If your Xvfb configuration was mandatory, and then Xvfb failed for some reason, then further boot would halt.

    You might ask which virtual desktops people have successfully used, and how they were added or configured. I don’t have a specific recommendation, but perhaps there are other virtual desktop servers (other than Xvfb) which are known to work.