C++ program autostart/start up

Hi! My problem is run C++ code for vision with ubuntu start. I complie code with Makefile and it work when I run it manual. It shows terminal with input from analyse. I’ve tried to put code to rc.local. I used “sudo systemctl status rc.local” comened. Termial showed “error while loading shared libraries…”. Do you have any idea how I can do it in a diffrent way or fix it this method?

What are the permissions from “ls -l /etc/rc.local”? Does your rc.local still start with:

#!/bin/bash

What is the line in rc.local which starts your program?

Does your program require a graphical desktop?

ls -l /etc/rc.local shows

-rwxr-xr-x 1 root root 53 Dec 19 12:23 /etc/rc.local

rc.local is

#!/bin/bash

/location/to/my/code/cv_code

My program require terminal to show datas from analise vision.

What is the permission for “/location/to/my/code/cv_code”? The script itself looks ok.

For your cv_code, does it access the GPU? If the program or a component of the program accesses the GPU (versus just data), then there needs to be a DISPLAY environment variable associating the program with an active display which the running user is authorized to display on. If you need a display before a user logs in, then you have to start the program with a different method than rc.local (rc.local is run prior to the GUI starting).

If you are already booted, can you manually start rc-local.service?

sudo systemctl start rc-local.service

If it fails, what dmesg is there?

Permission for cv_code

-rwxr-xr-x 1 root root 567248

same like rc.local

Job for rc-local service failed because the control process exited with error code. See "systemctl status rc-local.service" and "journalctl -xe" for details.

systemctl status rc-local.service shows

Dec 19 17:53:51 tegra-ubuntu systemd[1]: Starting /etc/rc.local Compatibility...
Dec 19 17:53:51 tegra-ubuntu rc.local[2176]: /location/to/code/cv_code: error while loading shared libraries: libntcore.so.1: cannot open shared object file: No such file or directory
Dec 19 17:53:51 tegra-ubuntu systemd[1]: rc-local.service: Control process exited, code=exited status=127
Dec 19 17:53:51 tegra-ubuntu systemd[1]: Failed to start /etc/rc.local Compatibility.
Dec 19 17:53:51 tegra-ubuntu systemd[1]: rc-local.service: Unit entered failed state.
Dec 19 17:53:51 tegra-ubuntu systemd[1]: rc-local.service: Failed with result 'exit-code'.

Permission for cv_code

-rwxr-xr-x 1 root root 567248

same like rc.local

sudo systemctl start rc-local.service

Job for rc-local service failed because the control process exited with error code. See "systemctl status rc-local.service" and "journalctl -xe" for details.

systemctl status rc-local.service shows

Dec 19 17:53:51 tegra-ubuntu systemd[1]: Starting /etc/rc.local Compatibility...
Dec 19 17:53:51 tegra-ubuntu rc.local[2176]: /location/to/code/cv_code: error while loading shared libraries: libntcore.so.1: cannot open shared object file: No such file or directory
Dec 19 17:53:51 tegra-ubuntu systemd[1]: rc-local.service: Control process exited, code=exited status=127
Dec 19 17:53:51 tegra-ubuntu systemd[1]: Failed to start /etc/rc.local Compatibility.
Dec 19 17:53:51 tegra-ubuntu systemd[1]: rc-local.service: Unit entered failed state.
Dec 19 17:53:51 tegra-ubuntu systemd[1]: rc-local.service: Failed with result 'exit-code'.

Do you know other methods to start program after GUI start.

PS. Sorry for double post.

What is in the program? What does it link to? One way to see is this:

ldd /location/to/code/cv_code

It is likely it does require GPU access. One way is to start a virtual desktop first. Another way, if you have a real monitor, would be something like:

startx /location/to/code/cv_code

startx can have parameters passed for things like resolution. This would create a new X instance on the first available console. A virtual desktop versus a physical monitor is indistinguishable to the program, it is just a case of setting the DISPLAY environment variable or naming the virtual server in the script. If you don’t mind using a real monitor, then you are ok just running startx.

Just to reiterate though, there must be a DISPLAY associated with a GUI program…a GUI or CUDA program expects a GPU environment. No environment, program fails…rc.local won’t be the reason why, but it will be where you see the failure.

ldd shows

linux-vdso.so.1 =>  (0x0000007f94bc1000)
	libopencv_core.so.2.4 => /usr/lib/libopencv_core.so.2.4 (0x0000007f94815000)
	libopencv_imgproc.so.2.4 => /usr/lib/libopencv_imgproc.so.2.4 (0x0000007f944d8000)
	libgstreamer-1.0.so.0 => /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0 (0x0000007f943b7000)
	libgobject-2.0.so.0 => /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0 (0x0000007f9435b000)
	libglib-2.0.so.0 => /lib/aarch64-linux-gnu/libglib-2.0.so.0 (0x0000007f94254000)
	libgstapp-1.0.so.0 => /usr/lib/aarch64-linux-gnu/libgstapp-1.0.so.0 (0x0000007f94237000)
	libgstriff-1.0.so.0 => /usr/lib/aarch64-linux-gnu/libgstriff-1.0.so.0 (0x0000007f94219000)
	libgstpbutils-1.0.so.0 => /usr/lib/aarch64-linux-gnu/libgstpbutils-1.0.so.0 (0x0000007f941d8000)
	libntcore.so.1 => /5883/ntcore/libntcore.so.1 (0x0000007f9401b000)
	libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007f93e8c000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f93ddf000)
	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007f93dbd000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f93c76000)
	/lib/ld-linux-aarch64.so.1 (0x0000005589e72000)
	libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000007f93c4f000)
	libcudart.so.8.0 => /usr/local/cuda-8.0/lib64/libcudart.so.8.0 (0x0000007f93beb000)
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f93bbf000)
	libtbb.so.2 => /usr/lib/aarch64-linux-gnu/libtbb.so.2 (0x0000007f93b80000)
	libgmodule-2.0.so.0 => /usr/lib/aarch64-linux-gnu/libgmodule-2.0.so.0 (0x0000007f93b6b000)
	libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f93b58000)
	libffi.so.6 => /usr/lib/aarch64-linux-gnu/libffi.so.6 (0x0000007f93b40000)
	libpcre.so.3 => /lib/aarch64-linux-gnu/libpcre.so.3 (0x0000007f93ace000)
	libgstbase-1.0.so.0 => /usr/lib/aarch64-linux-gnu/libgstbase-1.0.so.0 (0x0000007f93a67000)
	libgstaudio-1.0.so.0 => /usr/lib/aarch64-linux-gnu/libgstaudio-1.0.so.0 (0x0000007f93a02000)
	libgsttag-1.0.so.0 => /usr/lib/aarch64-linux-gnu/libgsttag-1.0.so.0 (0x0000007f939ba000)
	libgstvideo-1.0.so.0 => /usr/lib/aarch64-linux-gnu/libgstvideo-1.0.so.0 (0x0000007f93938000)
	librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007f93920000)
	liborc-0.4.so.0 => /usr/lib/aarch64-linux-gnu/liborc-0.4.so.0 (0x0000007f938a5000)

I will use nvidia without monitor.

When I had added startx to rc.local and reset jetson camera start blink two times and go off, what’s mean program is not working :(

CUDA is linked, so this requires GPU. The GPU driver and video driver are the same thing (one happens to have a monitor looking at the framebuffer, the other does not), so having a display implies having a driver which CUDA can talk to (a case where the name “display” is a bit misleading…perhaps a better word would be “gpu_context”…but environment variable name DISPLAY is what we’re stuck with).

Since you have no physical monitor you will need to install a virtual X server (the driver has what it will pretend is a monitor). Your application won’t care that the X server doesn’t have a monitor connected. If you have a virtual X server running, then you can use rc.local with startx (which also implies you could use remote desktop sharing software if desired, though this isn’t mandatory).

I don’t have any recommendations on a particular virtual X server, others may have experience they can share for that. This might be of interest since part of desktop sharing is installing a virtual X server on the Jetson:
https://devtalk.nvidia.com/default/topic/1001017/jetson-tx2/remote-desktoping-into-jetson-tx2-from-windows-10/post/5123184/#5123184
http://ubuntuhandbook.org/index.php/2016/07/remote-access-ubuntu-16-04/
https://devtalk.nvidia.com/default/topic/995621/jetson-tx1/jetson-tx1-desktop-sharing-resolution-problem-without-real-monitor/post/5159559/#5159559

Now I can start manualy program by VNC from my computer, but it doesn’t start with Ubuntu. Do I have to add some script to rc.local before “startx /location/to/code/cv_code”?

Perhaps a description of what is going on will clarify…

X has a graphical environment, and that environment is named in the DISPLAY environment variable. Traditionally, “export DISPLAY=:0” will name the first desktop, “export DISPLAY=:1” the second desktop (most systems only start the first desktop), so on (and there are extensions for naming a remote computer’s desktop which doesn’t exist on the local computer). When you start your application, and if the DISPLAY environment variable names a graphical environment prior to starting the application, then this is where the application runs. Virtual desktops count as such an environment.

If VNC has DISPLAY of “:1” (the second desktop), then "export DISPLAY=:1; " will do what you want because “:1” names a running environemnt. If VNC is not yet started and login has not yet occurred, then this will fail. VNC needs a login just like a real terminal, else the environment doesn’t exist.

For this environment to start someone has to log in to it. This is not automatic unless you go through steps to do so. The "startx " command logs in as the user who started startx and runs as its sole application (if happens to be a window manager…and most of the time it is…then the window manager itself can further run multiple programs at the same time). So to autostart an application you need to either associate it with a particular user’s GUI login, or run the application with DISPLAY set to some already running X GUI environment. No login, no environment.

Questions are:

  • Do you want a single application environment, or a full desktop?
  • Do you want an auto login?
  • Who do you want your login to run as?
  • Is there a real monitor also attached? Or is VNC the only one? (this changes the DISPLAY environment variable the app must use)