Potential ways to hack the bootup process to start our services and make custom tools available.

[hamishmb]

So, one thing we need to decide is how best to get any services we want to run running on bootup, and make our custom binaries available to the rest of the system. I have had a few ideas on this front:

• Have each pi attempt to SSH into the NAS box when they start up to execute a script on the HDD to set everything up.
  • This won't work if the network goes down, though.
  • Also, if the script takes a long time to execute, it will delay start up of the river system.
  • ^ Hence, my next idea.
• Have each pi SSH into the NAS and set up a temporary cron job to run this script.
  • This way there is minimal delay to the pis on startup.
  • This is still a kind of "tethered" hack though.
• Using some information I gleaned from the system files on the NAS, we might be able to define a cron job on startup.
  • If it works, probably the best idea, because it doesn't depend on another system to set itself up.
  • Also allows us to disable SSH in the final deployment, if we want to.
  • The script can then remove the cron job once the system is set up.

Any other ideas?

[TerryJC]

Hamish,

A clarification. Is this post about getting services to run on the NAS when it is started? Are we not able to access the NAS as root and define the services to run at boot-up. (Presumably we are talking pre-systemd here, so we'll have to dig into history to find out what to do, but as I recall this was all done in /etc/init.d.)

[hamishmb]

This is about starting services. This NAS box doesn't seem to use sysvinit, though. Also, we can't write to the NAND like that - we'd have to flash it to update those files, except (I think) for some special ones in /usr/local/config, which is where the options that can be configured from the web interface seem to be stored. There's a section for cron configuration in there, which is where my idea comes from. I did try other things, but most things are read-only, and the other files that are writeable seem to be transient and not saved to NAND.

[TerryJC]

Hmmm. OK. They do like to make things difficult don't they?

On balance, I prefer the cron job if it can be done because it's the nearest thing to the proper way to do it.

[hamishmb]

Indeed they do

Yeah, that's what I'm leaning towards as well.

[hamishmb]

Attached are the three useful-looking configuration files in /usr/local/config that we could hijack to add something to the crontab.

I have also attached /etc/rc.sh and two scripts from /usr/local/modules/script that look like they could be useful in understanding exactly how this thing boots up.

EDIT: Can't add /usr/local/modules/script/system_init, but you can find it in the archive in the NAND Dump thread at viewtopic.php?f=36&t=156.

[TerryJC]

Hamish,

The config.xml is not well formed, which is par for the course. We also have no schemas, so we can't validate any of the xml files. Having said that, if you are skilled in the art of parsing raw xml files, then these could be useful as you say. I worked with xml files for the last four years of my time at work and never really got my head round reading them without a decent xml editor (and we had several very expensive ones, apart from our product which generated and parsed the xml).

Having said that, even I can see roughly what they are doing and they mostly seem to be more about settings rather than services. Maybe you can make more sense of them.

Similarly, the shell scripts seem to be more related to setting up hardware than services.

Looking at your original opening remarks, the problem seems to be making sure our specially crafted binaries are properly run when the power is restored after shutdown or a reboot. I'm not sure what these might be, but for the database for example, presumably the database installed by the mySQLAdmin App will be started by the system once it's installed; couldn't we high-jack that? Not really cricket I know, needs must.

Just a thought.

[hamishmb]

Yeah, the one at /usr/local/modules/script/system_init is probably the most informative of how it sets itself up. Yes, probably, but I haven't yet found where that is started - I need to do some more digging.

The cron section in the XML files is mostly what I'm looking at. They seemed okay to me, didn't realise they weren't well-formed, but honestly not surprised.

[hamishmb]

So, unfortunately, my cron-job on startup hack doesn't seem to work. I modified the configuration, and uploaded it, and it did change config.xml persistently, but there is no cron job :/

I'll start writing my setup script for this stuff. Hopefully we can come up with another way/idea to make this work stand-alone.

[TerryJC]

It might be worth raising this on the LUG List or when we go to the Meeting on Tuesday.