rc-local service will dead after install cuda toolkit

Dear Sir
I got some problem about rc.local service
I find out that I cannot use this service after install cuda toolkit
This service will be ok without cuda toolkit

nvidia@tegra-ubuntu:~$ systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset:
Drop-In: /lib/systemd/system/rc-local.service.d
└─debian.conf
Active: inactive (dead)
Condition: start condition failed at Wed 2017-12-06 05:43:06 UTC; 4min 3s ago
ConditionFileIsExecutable=/etc/rc.local was not met

Dec 06 05:43:06 tegra-ubuntu systemd[1]: Stopped /etc/rc.local Compatibility.

Thanks for reporting this. I’ll check this.

Is rc.local not be able to restart for good??

There is no rc.local file in /etc
and I create rc.local file under /etc and restart it will shown as below

nvidia@tegra-ubuntu:~$ systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset:
Drop-In: /lib/systemd/system/rc-local.service.d
└─debian.conf
Active: inactive (dead)
Condition: start condition failed at Wed 2017-12-06 05:43:06 UTC; 4min 3s ago
ConditionFileIsExecutable=/etc/rc.local was not met

Dec 06 05:43:06 tegra-ubuntu systemd[1]: Stopped /etc/rc.local Compatibility.

As I know, ubuntu16.04 starts to use systemd to replace init.d so that there is no rc.local under /etc.

So you problem sounds like:
After you install jetpack3.1, you create a rc.local file under /etc and it works fine. However, after you install cuda toolkit (through jetpack?), rc.local fails to start permanently, right?

no
it will create rc.local automatically if I only install rootfs.
rc.local will disappear after I select to install cuda toolkit

Hi yi.chen,

rc.local is still running after I install cuda toolkit with Jetpack3.1.

did you reboot it?

Yes, after reboot, rc.local status is still active.

1.this one cannot use rc.local
nvidia@tegra-ubuntu:/$ sudo find -name “rclocal*”
./lib/systemd/system-generators/systemd-rc-local-generator
./lib/systemd/system/rc-local.service
./lib/systemd/system/rc-local.service.d
./lib/systemd/system/rc.local.service
./etc/init.d/rc.local
./etc/rc.local
./etc/rc4.d/S05rc.local
./etc/rc2.d/S05rc.local
./etc/rc3.d/S05rc.local
./etc/rc5.d/S05rc.local
find: ‘./run/user/1001/gvfs’: Permission denied

2.this one can use rc.local
nvidia@tegra-ubuntu:/$ sudo find -name “rclocal*”
./lib/systemd/system-generators/systemd-rc-local-generator
./lib/systemd/system/rc-local.service
./lib/systemd/system/rc-local.service.d
./lib/systemd/system/rc.local.service
find: ‘./run/user/1001/gvfs’: Permission denied
./run/systemd/generator/multi-user.target.wants/rc-local.service
./sys/fs/cgroup/systemd/system.slice/rc-local.service
./usr/src/kernel/kernel-4.4/rt-patches/0175-percpu_ida-Use-local-locks.patch
./home/nvidia/.config/chromium/Default/Local Storage/https_www.cyberciti.biz_0.localstorage
./home/nvidia/.config/chromium/Default/Local Storage/https_www.cyberciti.biz_0.localstorage-journal
./etc/rc.local
./etc/rc4.d/S05rc.local
./etc/init.d/rc.local
./etc/rc3.d/S05rc.local
./etc/rc2.d/S05rc.local
./etc/rc5.d/S05rc.local

Could you describe what did you do between these two cases?
Since I cannot reproduce this on my device, I think maybe you need to provide steps to reproduce issue in detail.

I record 3 videos about this issue
1.If use only l4t rc local is ok


2.use jetpack install l4t success and ready to install cuda

3.after install cuda and reboot rc.local is dead

What happens if you run:

sudo -s
systemctl enable rc-local.service
systemctl start rc-local.service
systemctl status rc-local.service
exit

nvidia@tegra-ubuntu:~ systemctl status rc-local.service ● rc-local.service - /etc/rc.local Compatibility Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset: Drop-In: /lib/systemd/system/rc-local.service.d └─debian.conf Active: inactive (dead) nvidia@tegra-ubuntu:~ sudo -s
[sudo] password for nvidia:
root@tegra-ubuntu:~# systemctl enable rc-local.service
root@tegra-ubuntu:~# systemctl start rc-local.service
root@tegra-ubuntu:~# systemctl status rc-local.service
● rc-local.service - /etc/rc.local Compatibility
Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset:
Drop-In: /lib/systemd/system/rc-local.service.d
└─debian.conf
Active: inactive (dead)
Condition: start condition failed at Thu 2017-12-07 05:07:29 UTC; 5s ago
ConditionFileIsExecutable=/etc/rc.local was not met

@linuxdev, Could you reproduce this problem on your device?

No, it works for me. I am using command line flash.sh though.

There are several simple things which might cause this to fail. It could be something very simple like file permissions (rc.local permissions or any of the files used with systemctl).

@yi.chen, what are the file permissions of (“ls -ld …”):

/etc/rc.local
/lib/systemd/system/rc-local.service.d
/lib/systemd/system/rc-local.service.d/debian.conf

What is the content of your “/lib/systemd/system/rc-local.service.d/debian.conf”?

@yi.chen, do you still have your old flash image file in “Linux_for_Tegra/bootloader/system.img.raw”? The significance of this is that it will show file permissions prior to extra package install…if something is off in those file permissions or content mentioned above, then this can be compared to a loopback mounted system.img.raw…differences could be attributed to extra packages instead of the flash itself.

nvidia@tegra-ubuntu:~ ls -ld /etc/rc.local ls: cannot access '/etc/rc.local': No such file or directory nvidia@tegra-ubuntu:~ ls -ld /lib/systemd/system/rc-local.service.d
drwxr-xr-x 2 root root 4096 Jun 3 2016 /lib/systemd/system/rc-local.service.d
nvidia@tegra-ubuntu:~ ls -ld /lib/systemd/system/rc-local.service.d/debian.conf -rw-r--r-- 1 root root 290 May 12 2016 /lib/systemd/system/rc-local.service.d/debian.conf nvidia@tegra-ubuntu:~ cat /lib/systemd/system/rc-local.service.d/debian.conf
[Unit]

not specified by LSB, but has been behaving that way in Debian under SysV

init and upstart

After=network-online.target

Often contains status messages which users expect to see on the console

during boot

[Service]
StandardOutput=journal+console
StandardError=journal+console
nvidia@tegra-ubuntu:~ ^C nvidia@tegra-ubuntu:~ systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset: enabled)
Drop-In: /lib/systemd/system/rc-local.service.d
└─debian.conf
Active: inactive (dead)

Don’t know what your system.img.raw mean
Is there any document about that?

No rc.local implies the service cannot run.

I am looking at a fresh JetPack 3.1 install. The “Linux_for_Tegra/rootfs/etc/rc.local” is there, and the system.img.raw file has this. The actual Jetson, after package install, no longer has this file. It looks like part of the process of sending the IP address to the JetPack/host is responsible for breaking this.

You can put this in to replace the file (it should have nothing but comments after JetPack is done), or just “sudo touch /etc/rc.local”:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

From what I can tell JetPack wants rc.local to cause the Jetson to send its IP address to JetPack via temporary file “/tmp/jetpack.log”. Most likely after this first boot is done the temp IP address code is removed…only it has a bug and it doesn’t remove the code…it removes the entire file. The file needs to be left in place. It is a JetPack 3.1 bug (and perhaps other versions, I have not looked).

This is my tx1 result after installing cuda-toolkit through IP address and reboot.

nvidia@tegra-ubuntu:/etc$ systemctl status rc-local.service
● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset: enabled)
  Drop-In: /lib/systemd/system/rc-local.service.d
           └─debian.conf
   Active: active (exited) since Tue 2017-12-12 02:37:17 UTC; 1min 41s ago
  Process: 629 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)

Dec 12 02:37:17 tegra-ubuntu systemd[1]: Starting /etc/rc.local Compatibility...
Dec 12 02:37:17 tegra-ubuntu rc.local[629]: /etc/rc.local: 16: /etc/rc.local: /home/nvidia/report_ip_to_host.sh: not found
Dec 12 02:37:17 tegra-ubuntu systemd[1]: Started /etc/rc.local Compatibility.

I see jetpack does not remove rc.local here. @linuxdev, do you also see it delete the file?

When I flash on command line the file is there. I just flashed a TX2 with JetPack 3.1 and added a few packages, e.g., CUDA. The file is indeed missing. rc.local has content which is obviously designed to get a freshly rebooted Jetson to give its IP address to JetPack for package installs, and JetPack did indeed automatically get the address correctly. My guess is that JetPack then removes this content, but does it incorrectly…removing the entire file instead of just the code.

If I look at the loopback image from system.img.raw I see that rc.local is there…thus it had been there after the flash. The content should be this:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

touch /tmp/jetpack.log
echo "starting script to send ip to host" >> /tmp/jetpack.log
/home/nvidia/report_ip_to_host.sh &
echo "started script to send ip to host" >> /tmp/jetpack.log

exit 0