0

I added this to the file /etc/rc.local, just before the exit 0

cd ~/Dekstop
bash play_video.sh

The script on the desktop contains this:

#!/bin/bash
omxplayer --loop  --blank video.mp4

After booting nothing is happening. What is wrong?

clankill3r
  • 202
  • 1
  • 3
  • 10

2 Answers2

3

I totally agree with @goldilocks about the requirement of a non blocking call.

But there is still a bug in the command. Which desktop is referred by ~/Desktop, pi's or root's?

As long as you don't explicitly imply the user to execute a command in rc.local, they are executed in user space of root.

The most clean way is to work with absolute paths:

nohup /usr/bin/omxplayer --loop --blank /home/pi/Desktop/video.mp4 1>/var/log/myomx.log 2>/var/log/myomx.err &

Update #1: Editing rc.local should be the last choice. You can also check this answer. It may be more suitable for your target.

vaha
  • 1,240
  • 2
  • 11
  • 20
  • Hey whoops I missed that one -- it would work out to /root/Desktop, not /home/pi/Desktop, and the former doesn't even exist by default, so likely the cd just fails then there's no script to execute. Use of nohup here can't hurt either. – goldilocks Oct 20 '16 at 18:23
2

/etc/rc.local must exit reasonably quickly or it will be killed by the init system. I do not know what if any hard and fast figure this would be, but as a rule of them, aim for no more than 5-10 seconds and ideally much less than that.

Part of what is at issue is that this will block the completion of the boot process. If your goal here is to play a video in a loop I imagine this does not matter to you, but you are going about it the wrong way (which is a separate question).

You can start long running processes from rc.local, but rc.local itself must be able to exit. This means those process must fork into the background. This:

bash play_video.sh

Is a blocking call. It does not return until play_video.sh is finished, which in this case is an indefinite period of time probably much longer than just a few seconds.

To get around this problem, execute the script in a subshell and fork it to the background instead:

(
    cd /home/pi/Desktop # Don't use a tilde! Use an explicit, complete path.
    exec ./play_video.sh
) &

The parentheses are the subshell, which is a new child process. When rc.local exits it will be adopted by init.

Presuming the script is marked executable, you do not need bash there as there is a shebang (#!) to that effect at the beginning. exec means replace this process with the one specified. In this case it would be in theory more efficient to replace ./play_video.sh with the omxplayer line, although it is not a significant difference and you may want to keep the separate script to make debugging easier (e.g., so you can write something before and after executing omxplayer to a log).

The & is the fork. This means that command (the subshell) will return immediately and rc.local can exit.

With regard to debugging this may be of interest:

Log output of background or boot script

I believe the problem you will run into implied earlier, about this being the wrong methodology, is that omxplayer isn't going to work from the background, but it is a bit special and I could be wrong. It is at least worth a try.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • What about using /etc/profile? – clankill3r Mar 08 '17 at 14:38
  • @clankill3r /etc/profile does not fire at boot, it fires at login -- so if you have autologin set up it will fire at boot, but it will also fire at subsequent logins. That's subject to a caveat: Some display managers, which are the programs that present a graphical login, may circumvent this (I believe lightdm, which is the default used on Raspbian is among them). Additionally, whatever's run will run as the login user and may encounter certain complications if it is supposed to be a persistent background process. – goldilocks Mar 09 '17 at 10:25
  • So, in general no, /etc/profile is not a good choice for starting things at boot, although it may work under certain circumstances. It isn't any easier than using /etc/rc.local anyway. – goldilocks Mar 09 '17 at 10:25