Scripts and /etc/rc.local on bootup

Costas Costas

I have some bash scripts that takes snapshots from my USB and IP cameras and emails them to me from the Omega.

These scripts works fine but simple scripts to reboot the device (reboot -d 1) or change the LED status on the Omega don't work.

They work fine if I run the script and they work fine if I run . /etc/rc.local but the scripts are not available on bootup as expected from /etc/rc.local.

Once the system has booted up if I kill /etc/rc.local and then run it manually the scripts are fine but not directly from bootup.

Is there something special I need to do to make simple system commands available? As I say more complex scripts like take a snapshot and emailing it works fine on bootup in /etc/rc.local but not the simple stuff.

fossette

@Costas-Costas Any error reported in the system log files? Absolute paths to commands are needed in a system file. Maybe some of the needed system components are not fully loaded when you perform your request. Some people have added a sleep command in the script to give the system a better chance.

Costas Costas

Thanks @fossette

I am using the full paths but I will try the sleep fix to see if it helps and check the logs.

Do we use & after the scripts with this version of openwrt like we do generally in linux?
Tried with and without but no joy.

fossette

@Costas-Costas The & at the end of a command is a request to run the command immediately in parallel (here, parallel to the boot process). This is the perfect technique for very long user made projects or script that runs continuously.

It's a bad idea to use & at the end of a sleep command line because it will run in parallel, thus having no effect at all on your boot process.

Kit Bishop

@fossette @Costas-Costas Yes, I would definitely recommend putting & at the end of any commands in rc.local that are going to take a long time (or run permanently) - this will run the command in the background as is standard for Linux systems - otherwise rc.local won't complete until they have and this will block your further access.
Putting & on sleep is pointless - you want it to run to completion before proceeding. With &, sleep would run in the background and not really achieve anything

Kit Bishop

@Costas-Costas In your original post, you say:

I have some bash scripts ...

Do you specifically use bash?
The Omega standardly uses ash as its shell, though bash can be installed.

In general, ash and bash are pretty well compatible with ash being a bit more light weight.
I have been unable to ascertain significant differences in usage between the two and (so far) have had no problems assuming ash behaviours the same as bash so have never bothered to install bash

A brief run down of the ash shell (also known as the Almquist shell) can be found here: https://en.wikipedia.org/wiki/Almquist_shell
It is also the basis of the dash shell used by Debian and Ubuntu

Costas Costas

@Kit-Bishop I haven't installed bash and I am using the default Omega ash.

I guess it doesn't matter that the scripts start with:

#!/bin/sh

It's not that the scripts will not run it's just that some built in commands (e.g. LED control with echo command) are not running on bootup from /etc/rc.local but after bootup they run for . /etc/rc.local

I will try sleep etc but syslog doesn't show any entries at the moment. Do I need to set a logging level?

Costas Costas

Thank you @fossette and @Kit-Bishop the 'ash' scripts are now running on bootup.

It turned out to be a path issue.
I was running the scripts as a child process within node.js and the complex scripts had full paths but I had missed them off the basic change LED status scripts.

I also worked out that logread provides access to the system log and further details are available at https://wiki.openwrt.org/doc/howto/log.essentials

This leads on to 1 or 2 related questions.
Another child process 'ash script in node.js calls is this command

reboot -d 1

It appears that because /etc/rc.local and my node.js processes are still running it will not accept the reboot request (even with the correct path for the script).

If I manually kill the process then the Omega (2+) will reboot but I need an automated procedure.

Does any one know how I might do this? I believe there are some fancy grep routines that could run in a script and kill the /etc/rc.local process but I was hoping for something a little more straightforward than that.

The final point relates to the system clock. If I kill the /etc/rc.local it seems to crash the system time and reset at approx 111 minutes prior to the real clock time. I could understand it if it was out by 120 minutes as this is my timezone adjustment.

Where is the Omega picking up this weird system time following the kill process?
For reference /etc/config/system has the correct settings for timezone etc.

fossette

@Costas-Costas , if you launch your script from /etc/rc.local using &, /etc/rc.local will eventually terminate by itself. You just need to have a long enough sleep command inside your script.

Costas Costas

@fossette I found that I didn't need sleep or & for my scripts to run, it was simply a bad path.

Just to add a few more details the current routine is:

An ash script in /etc/rc.local calls another ash script that runs a node.js script.
All this is done without sleep and &.
The node.js script never stops as it needs to run at all times unless the reboot command is requested from the Smartphone app that is tied to the script.
I will try with a single ash script rather than the two I am currently using as it might work better with the correct path's. Will also test out & to see if that will let me run the reboot command.

Costas Costas

No amount of sleep or & works with node.js.
node.js is notoriously difficult to start on boot up for regular linux systems and normally requires forever and forever-service.
Not sure if this is available for Omega hardware but I can reliably start node.js with the 2 ash scripts. First script being in /etc/rc.local

I just can't reboot the Omega via a script when node.js is started with the 2 scripts from bootup.

Maybe I'll have to go hunting for the grep and kill process routine.
Does anyone happen to have an ash script for finding and killing a process for example called rstomega ?

Costas Costas

Ok I think I have worked out the command.

kill $(ps | grep '[r]'c.local | awk '{print $1}')

Will test in my scripts but this procedure does seem to trash the time settings.

Costas Costas

Working script to reboot Omega when scripts are started with /etc/rc.local

#!/bin/sh
# reboot Omega script by Costas for scripts started with /etc/rc.local
pid1=$(ps | grep '[r]'c.local | awk '{print $1}')
echo $pid1 >> /root/reboots.txt
echo "Process number to kill is:" $pid1
kill -9 $pid1
sleep 20
reboot -d 1
# line above DOESN'T WORK FOR SCRIPTS STARTED WITH /etc/rc.local
# unless you kill /etc/rc.local first
echo "Please wait for your Omega to reboot"

I just need to know why the system reboot time for the Omega is set at 13:16:43 (maybe firmware build time perhaps). Will start a new thread for this.

Chris Stratton

Putting things in rc.local is a bit of an expedient measure, and the shutdown issue starts to show the limitiations.

Formally, the way you're supposed to configure long-running services on a system with this type of setup is to make an entry for each one in /etc/init.d which can be setup both with commands to run on startup and on shutdown, and also gives you command line access to start/stop the service.

https://wiki.openwrt.org/doc/techref/initscripts

Costas Costas

@Chris-Stratton in due course I will look at /etc/init.d but I never want to stop the service. What I want to be able to do is reboot the Omega. Maybe a regular reboot -d 1 will work if I use /etc/init.d for node.js rather than /etc/rc.local

Chris Stratton

@Costas-Costas said in Scripts and /etc/rc.local on bootup:

@Chris-Stratton in due course I will look at /etc/init.d but I never want to stop the service.

Actually stopping the service appears to be exactly what you need to do in order to cleanly reboot - which is why the formal method creates both startup scripts that run automatically on startup, and shutdown scripts that run automatically on shutdown (to power-off or reboot).

Another reason for being able to start/stop it at the command line is if you are doing work on the system - for example if you want to copy a new version of the executable and configuration files and then start it up again using those, without doing a reboot.

Costas Costas

@Chris-Stratton actually you are right and as long as my script then includes the reboot -d 1 I should be fine.

The Omega is a remote device controlled by a Smartphone app (Blynk) so once node.js is terminated there is no control from the app. Therefore the only command that can be issued after terminating node.js is reboot. No system admin or the like, just a reboot so the app has control again of the Omega.

Chris Stratton

The complication that you face in trying to do a custom shutdown is that you'll be shutting down the thing that begins your reboot, before it needs to begin it. That can be done, but requires that the commands not be tied to their parent process, so that they can outlive its death.

Perhaps what you should be doing is triggering the system reboot command, and letting that shut down your service and everything else automatically, in configured order, and (if everything is setup right) then reboot.

FWIW if you anticipate frequent reboots or unexpected power loss, and have limited or no need for persistent storage modifiable at runtime, I'd consider running the system from a ram disk, which makes a hard reboot safe. On the downside that means that any need for persistent storage has to be explicitly handled; on the upside, you get to control exactly how the storage is done and when it is flushed to a shutdown-safe state.

Costas Costas

Tried that, doesn't work.

reboot -d 1 will not reboot an Omega that is running my script from /etc/rc.local.
Need to test if it will reboot a /etc/init.d script.

Not expecting to have to do reboots but I like to know it's available remotely if required.

Chris Stratton

@Costas-Costas said in Scripts and /etc/rc.local on bootup:

Tried that, doesn't work.

reboot -d 1 will not reboot an Omega that is running my script from /etc/rc.local.

Because it has no way of stopping that script to get the system to a safely rebootable state. Or more importantly its children - the script itself should have done its work and completed shortly after boot, not continued to run.

Need to test if it will reboot a /etc/init.d script.

When properly setup, a properly setup and invoked reboot command should run the shutdown side of your script to top your custom service, get the system to a safely rebootable state, then reboot it.

You can of course invent new ways of doing things; the point is that there's already a mechanism for doing this, which is available if the system and your extensions to it are correctly configured.