Simple question: Is there anywhere I can dump a script file that will cause it to get run on startup? System is Debian (actually Raspbian although it could apply to other Debian derivatives). On this occasion it has a GUI but I'm looking for something that would work in a GUI-less environment. Caveats: What I want to do is just copy a file there (eg dropping files onto the SD card of a Pi). I'm trying to keep things simple so ideally I don't want to edit any files, which means appending to rc.local is out, for example. I tried creating /etc/cron.d/mystuff with @reboot root /root/mystuff.sh .. which works fine on reboot but doesn't run from any other startup, so not what I need. I'm thinking about creating a script for /etc/rc.d and also creating all the symlinks manually that would otherwise be created by update-rc.d, but that's messy. It seems odd that there isn't a /etc/rc.local.d directory (or similar) which automatically runs all scripts present at the end of rc.local, but unless I'm missing something there isn't any such approach. (Background: I want a simple way to configure a Pi (or similar) by writing the latest Raspbian image to a disk then extracting a tar file of my changes over the top. I want to supplement existing files rather than replace any that could obviously change between Raspbian versions.) -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On Mon, Mar 07, 2016 at 06:02:19PM +0000, Mark Rogers wrote:
Simple question: Is there anywhere I can dump a script file that will cause it to get run on startup?
System is Debian (actually Raspbian although it could apply to other Debian derivatives). On this occasion it has a GUI but I'm looking for something that would work in a GUI-less environment.
Caveats: What I want to do is just copy a file there (eg dropping files onto the SD card of a Pi). I'm trying to keep things simple so ideally I don't want to edit any files, which means appending to rc.local is out, for example.
Can't you add something to rc.local that would look for files in the SD card and execute them? You'd need to change rc.local once but that's all. -- Chris Green
On 7 March 2016 at 18:31, Chris Green <cl@isbd.net> wrote:
Can't you add something to rc.local that would look for files in the SD card and execute them? You'd need to change rc.local once but that's all.
The SD card is where the OS is. Any time I re-image I'll need to make the same edits. Ie the "workflow" is: - Download latest Raspbian disk image from the Pi website - Use dd to copy it to SD (ie overwriting what's there) - Use tar to extract a set of my files over the top of the freshly created SD card - Eject SD card and boot the Pi from it I can add a step that makes various edits as well as just replacing files but so much of the Debian system is based around not editing system files but adding your own alongside (eg /etc/cron.d, /etc/apache2/conf.d) that it seems odd that something as fundamental as "run this on startup" isn't covered in the same way. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On Tue, Mar 08, 2016 at 12:56:55PM +0000, Mark Rogers wrote:
On 7 March 2016 at 18:31, Chris Green <cl@isbd.net> wrote:
Can't you add something to rc.local that would look for files in the SD card and execute them? You'd need to change rc.local once but that's all.
The SD card is where the OS is. Any time I re-image I'll need to make the same edits.
Ah, yes I see, of course, it's a Pi isn't it.
Ie the "workflow" is: - Download latest Raspbian disk image from the Pi website - Use dd to copy it to SD (ie overwriting what's there) - Use tar to extract a set of my files over the top of the freshly created SD card - Eject SD card and boot the Pi from it
I can add a step that makes various edits as well as just replacing files but so much of the Debian system is based around not editing system files but adding your own alongside (eg /etc/cron.d, /etc/apache2/conf.d) that it seems odd that something as fundamental as "run this on startup" isn't covered in the same way.
Won't *any* executable file in the appropriate /etc/rcX.d directory get executed for that run level? Your tar extract can just put an executable in the appropriate run-level directory (or directories) can't it? -- Chris Green
On 8 March 2016 at 14:09, Chris Green <cl@isbd.net> wrote:
Won't *any* executable file in the appropriate /etc/rcX.d directory get executed for that run level?
I honestly don't know - and it's a subject where there's so much documentation that it's hard to see the wood for the trees! My understanding is that the script should at least respond to start/stop parameters but I might be wrong - especially as in this case where there is no service being started, i just want some code to run once to initialise some scripts. And then systemd confuses things further (or does it?). Any advice on the use of rc.X would be appreciated. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On Wed, Mar 09, 2016 at 10:10:29AM +0000, Mark Rogers wrote:
On 8 March 2016 at 14:09, Chris Green <cl@isbd.net> wrote:
Won't *any* executable file in the appropriate /etc/rcX.d directory get executed for that run level?
I honestly don't know - and it's a subject where there's so much documentation that it's hard to see the wood for the trees!
:-)
My understanding is that the script should at least respond to start/stop parameters but I might be wrong - especially as in this case where there is no service being started, i just want some code to run once to initialise some scripts.
Yes, I think you're right. All the scripts are just symbolic links to the scripts in /etc/init.d and those do expect 'start', 'stop', 'restart' etc. Presumably init (or whatever has replaced it) runs the scripts with an appropriate 'start' or 'stop' depending on the run-level. So if you create a script that allows a 'start' parameter (just ignores it) and put it in the appropriate /etc/rcX.d I think that should work.
And then systemd confuses things further (or does it?).
Probably! However I think it still allows for 'legacy' code to work. -- Chris Green
On 9 March 2016 at 10:58, Chris Green <cl@isbd.net> wrote:
And then systemd confuses things further (or does it?).
Probably! However I think it still allows for 'legacy' code to work.
On the other hand, since the world and his dog seem to have gone to systemd, does anyone know how I should accomplish what I need in a systemd-native way? -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On Wed, Mar 09, 2016 at 12:43:07PM +0000, Mark Rogers wrote:
On 9 March 2016 at 10:58, Chris Green <cl@isbd.net> wrote:
And then systemd confuses things further (or does it?).
Probably! However I think it still allows for 'legacy' code to work.
On the other hand, since the world and his dog seem to have gone to systemd, does anyone know how I should accomplish what I need in a systemd-native way?
... but has the RaspberryPi yet gone to systemd? -- Chris Green
On Wed, Mar 09, 2016 at 02:10:51PM +0000, Chris Green wrote:
On Wed, Mar 09, 2016 at 12:43:07PM +0000, Mark Rogers wrote:
On the other hand, since the world and his dog seem to have gone to systemd, does anyone know how I should accomplish what I need in a systemd-native way?
... but has the RaspberryPi yet gone to systemd?
Raspbian is based on Debian and jessie uses systemd by default (though you can tell it to use sysvinit if you want). My fairly untouched Raspbian 8 install is using systemd. J. -- Beware of programmers carrying screwdrivers.
On Wed, Mar 09, 2016 at 02:18:36PM +0000, Jonathan McDowell wrote:
On Wed, Mar 09, 2016 at 02:10:51PM +0000, Chris Green wrote:
On Wed, Mar 09, 2016 at 12:43:07PM +0000, Mark Rogers wrote:
On the other hand, since the world and his dog seem to have gone to systemd, does anyone know how I should accomplish what I need in a systemd-native way?
... but has the RaspberryPi yet gone to systemd?
Raspbian is based on Debian and jessie uses systemd by default (though you can tell it to use sysvinit if you want). My fairly untouched Raspbian 8 install is using systemd.
Ah, my (kept up to date) Pi is on Raspbian 7, that still uses init. Is there any upgrade path between Raspbian versions? -- Chris Green
On 09/03/16 14:36, Chris Green wrote:
On Wed, Mar 09, 2016 at 02:18:36PM +0000, Jonathan McDowell wrote:
On Wed, Mar 09, 2016 at 02:10:51PM +0000, Chris Green wrote:
On Wed, Mar 09, 2016 at 12:43:07PM +0000, Mark Rogers wrote:
On the other hand, since the world and his dog seem to have gone to systemd, does anyone know how I should accomplish what I need in a systemd-native way?
... but has the RaspberryPi yet gone to systemd? Raspbian is based on Debian and jessie uses systemd by default (though you can tell it to use sysvinit if you want). My fairly untouched Raspbian 8 install is using systemd.
Ah, my (kept up to date) Pi is on Raspbian 7, that still uses init.
Is there any upgrade path between Raspbian versions?
Append your code to the end of the text file /etc/rc.local That gets run on every boot. Steve
On 9 March 2016 at 21:52, <steve-ALUG@hst.me.uk> wrote:
Append your code to the end of the text file /etc/rc.local That gets run on every boot.
I'm trying to avoid modifying system files because I want to be able to take a fresh Raspbian install and drop my own files over the top of it, whilst at the same time being as robust as possible in case of changes in the Raspbian image. Replacing rc.local leaves me vulnerable to a modification in the source. (Just appending is easy but it means scripting something rather than just extracting a tar file over the top of the restored image. And and such installation script should really check for the presence of the changes before it appends, in case the script gets re-run, whereas re-extracting the tar file doesn't have that problem.) -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
In the end I went down the route of having a script in init.d. An example script ("my-script") follows for the benefit of anyone interested. It should be /etc/init.d, owned by root, chmod +x. Then sudo update-rc.d my-script defaults .. creates the relevant symlinks, although for my purposes I'll have to add those symlinks into my tar backup so they get installed automatically. Mark #!/bin/bash # my-script Example startup script # # Version: @(#)my-script 1.00 10-Mar-2016 mark@xxx # # Patches: ### BEGIN INIT INFO # Provides: my-script # Required-Start: $local_fs # Required-Stop: # Should-Stop: # Default-Start: S # X-Start-Before: # Default-Stop: 0 6 ### END INIT INFO case $1 in start|restart) # Some stuff here ;; stop) # Some stuff here, if I want ;; status|info) # Some stuff here, if I want ;; *) # Some stuff here, if I want ;; esac exit 0 -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
Is there any upgrade path between Raspbian versions?
Officially, apt-get update ; apt-get dist-upgrade, after adding the new repos to /etc/apt/sources.list Described here: https://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.html <https://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.html> Unofficially, both R-Pi I’ve done this to have seemed to work fine, but now have trouble getting to 48hours uptime. I’ve re-imaged one, and will do the other when I can be bothered. Bill
participants (5)
-
Chris Green -
Jonathan McDowell -
Mark Rogers -
steve-ALUG＠hst.me.uk -
William Hill