Scripts and /etc/rc.local on bootup
-
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.
-
Putting things in
rc.localis 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.dwhich 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.
-
@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
-
@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.
-
@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.
-
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.
-
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.
-
@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.
-
Warning init.d in the wrong hands is dangerous!
@Chris-Stratton I set up init.d, but badly and now I'm locked out of the Omega (2+).
I removed the & from the node.js call because I thought it was making the script restart when I stopped it. I think actually the node.js script has inbuilt restart as the service should run at all times.
In the init.d script I set START=40 and I'm guessing this is before ssh kicks in and without the & my perpetual node.js script has taken over control of the Omega.
I still have Smartphone control of the Omega, excluding reboot but I can't make any further changes to it. I don't use any of those dock things.
What is the process for resetting the Omega now that i'm locked out?
-
@Costas-Costas said in Scripts and /etc/rc.local on bootup:
Warning init.d in the wrong hands is dangerous!
root access in the wrong hands is dangerous, but less so on a system with so little corruptible state (until you get to interacting with the uboot and firmware partitions)
@Chris-Stratton I set up init.d, but badly and now I'm locked out of the Omega (2+).
Only if you rely on the network for maintenance while developing, which would be a problem sooner or later anyway. This is what safe mode on the serial console is for - it boots without the overlay containing your changes.
Or you can do a factory reset via the button.
Given the way these systems store changes, you need to be backing up your work anyway.
-
@Chris-Stratton I will try console access shortly but I did try"reset" earlier without success.
I have the latest firmware. Should reset just be held to ground for up to 30 seconds and does it only kick in if you do it on reboot?
-
@Chris-Stratton console access worked just fine, phew.
Will changing START=40 to something like START = 100 allow ssh to kick in before my init.d script?
I have added the & to my node.js call but I'm not convinced it will work because the node.js script is self perpetuating.Still interested to know from anyone how reset to factory firmware is done with the rst pin.
-
@Costas-Costas said in Scripts and /etc/rc.local on bootup:
@Chris-Stratton console access worked just fine, phew.
Will changing START=40 to something like START = 100 allow ssh to kick in before my init.d script?
That's probably not a workable goal - even if you get the ssh server up first, you may not have network connected yet, have had a chance to use it yet, etc.
Generally, if you are going to have a system with only radio access, you first test heavily on a system that has serial console access, and changes only make it o the radio-based system after they have been well proven.
More complex systems sometimes include an auto-rollback to an older stable version or a maintenance mode (in your case, ssh but not node red), for example by leaving indications behind that can be seen on startup after a crash. It looks like the MT7688 has some registers intended for this kind of usage, which is simpler than trying to do it with magic values in main memory and then having to make sure that they don't get lost in DDR re-initialization, or startup memory walking.
Essentially you could do something like this:
- on boot, if register is blank set it to UNCOMMANDED_REBOOT_1
- if it is already UNCOMMANDED_REBOOT_1 set it to UNCOMMANDED_REBOOT_2
- if it is UNCOMMANDED_REBOOT_2 startup in safe mode.
When commanding a reboot, first set the register to REBOOT_COMMANDED so it is clear that this was intentional and not a crash.
-
@Chris-Stratton If I understand you right, you want to start a script at start up time from init.d, the script you are starting is to carry on running once init.d has completed but you want your script to be started only once ssh server is fully up.
What I would suggest you do is create an additional shell script (e.g. call it startmyscript.sh for reference any name will do). Create the file startmyscript.sh containing something like:
sleep <nnn> scritptorunWhere <nnn> is some period long enough for ssh server to start up
and scripttorun is the name of the script to runMake this executable by running the command (once only needed):
chmod +x startmyscript.shThen in init.d (I would suggest at the end but at least after the point where ssh server is started) add the line:
<path>/startmyscript.sh &where <path> is the full path to the directory where startmyscript.sh is kept
This will cause startmyscript.sh to be run as a separate background task. The first thing this does is sleep for the given time, then and only then will it run your script
-
@Kit-Bishop said in Scripts and /etc/rc.local on bootup:
@Chris-Stratton If I understand you right, you want...
No, I have no such need, but was merely responding to someone
sleep <nnn> scritptorunThis is unsafe - it assumes that the prerequisite operations will take a given amount of time, which when they involve things like wifi network registration is simply not valid.
Well designed systems use positive event linkage, not delays.
-
@Chris-Stratton I have moved back to rc.local for now as it is much safer than init.d for a novice like me. rc.local is working flawlessly. As the Omega is a "router" my understanding is that killing processes is no different to switching the power off and back on, which Omega state is fine.
Do you have a link to the registers for the MT7688?
-
@Costas-Costas said in Scripts and /etc/rc.local on bootup:
@Chris-Stratton As the Omega is a "router" my understanding is that killing processes is no different to switching the power off and back on, which Omega state is fine.
No, there is in fact substantial difference, and no, arbitrarily pulling power is not safe.
The key issue is that the stock configurations use a writeable filesystem overlay, and if you pull power from that at an inappropriate time you can end up with bad state there; in theory the journaling provides some protection from this, in practice there still appears to be some risk.
The point of an orderly shutdown is that you tell the system to stop all new access to persistent storage, flush changes, and leaves things in a known good state.
In the typical shipped configurations, the fallback to a broken writeable overlay is the factory reset back to the underlying main partition, which should have been write-only the whole time, and so (at least on these SPI flashes) safe from incompleted-write corruption.
Do you have a link to the registers for the MT7688?
They're in one of the versions of the data sheet can be found online
-
@Chris-Stratton thanks for your feedback.
Until such time as Onion change their stance on powering off their device or one of my Omega's fails I will reboot with the procedure I am currently using.
