You'll need to download the content of the script in some way. You could do
ssh remote-host cat script.bash | bash
But that would have the same kind of problem as:
cat script.bash | bash
namely that stdin within the script would be the script itself (which could be an issue if commands within the script need to get some input from the user).
Then, a better alternative (but you'd need a shell with support for process substitution like ksh, zsh or bash) would be:
bash <(ssh remote-host cat script.bash)
Both approaches do download the script in that they retrieve its content, but they don't store it locally. Instead the content is fed to a pipe whose other end is read and interpreted by bash
.
You can also have the content of the remote script executed in the current bash process with:
eval "$(ssh remote-host cat script.bash)"
But that downloads the script fully (and stores it in memory) before running it.
The obvious solution would be to do:
. <(ssh remote-host cat script.bash)
But beware that some versions of bash have issues with that.
This can be a bit of a confusing topic because there are different implementations of cron. Also there were several bugs that broke this feature, and there are also some use cases where it simply won't work, specifically if you do a shutdown/boot vs. a reboot.
Bugs
datapoint #1
One such bug in Debian is covered here, titled: cron: @reboot jobs are not run. This seems to have made it's way into Ubuntu as well, which I can't confirm directly.
datapoint #2
Evidence of the bug in Ubuntu would seem to be confirmed here in this SO Q&A titled: @reboot cronjob not executing.
excerpt
comment #1: .... 3) your version of crond may not support @reboot are you using vix's crond? ... show results of crontab -l -u user
comment #2: ... It might be a good idea to set it up as an init script instead of relying on a specific version of cron's @reboot.
comment #3: ... @MarkRoberts removed the reboot and modified the 1 * * * * , to */1 * * * * , problem is solved! Where do I send the rep pts Mark? Thank you!
The accepted answer in that Q&A also had this comment:
Seems to me Lubuntu doesn't support the @Reboot Cron syntax.
Additional evidence
datapoint #3
As additional evidence there was this thread that someone was attempting the very same thing and getting frustrated that it didn't work. It's titled: Thread: Cron - @reboot jobs not working.
excerpt
Re: Cron - @reboot jobs not working
Quote Originally Posted by ceallred View Post
This is killing me... Tried the wrapper script. Running manually generates the log file... rebooting and the job doesn't run or create log file.
Syslog shows that CRON ran the job... but again, no output and the process isn't running.
Jul 15 20:07:45 RavenWing cron[1026]: (CRON) INFO (Running @reboot jobs)
Jul 15 20:07:45 RavenWing CRON[1053]: (ceallred) CMD (/home/ceallred/Scripts/run_spideroak.sh > /home/ceallred/Scripts/SpiderOak.log 2>&1 &)
It's seems like cron doesn't like the @reboot command.... Any other ideas?
Okay... Partially solved. I'll mark this one as solved and start a new thread with the new issue.....
I think the answer was my encrypted home directory wasn't mounted when CRON was trying to run the script (stored in /home/username/scripts). Moved to /usr/scripts and the job runs as expected.
So now it appears to be a spideroak issue. Process starts, but by the time the boot process is finished, it's gone. I'm guessing a crash for some reason.... New thread to ask about that.
Thanks for all the help!
Once this above user figured out his issue he was able to get @reboot
working out of the crontab entry of a user.
I'm not entirely sure what version of cron is used on Ubuntu, but this would seem to indicate that user's can use @reboot
too, or that the bug was fixed at some point in subsequent versions of cron.
datapoint #4
I tested on CentOS 6 the following and it worked.
Example
$ crontab -l
@reboot echo "hi" > /home/sam/reboot.txt 2>&1
I then rebooted the system.
$ sudo reboot
After the reboot.
$ cat reboot.txt
hi
Take aways
- This feature does seem to be supported for both system and user crontab entries.
- You have to make sure that it's supported/working in your particular distro and/or version of the cron package.
For more on how the actual mechanism works for @reboot
I did come across this blog post which discusses the innards. It's titled: @reboot - explaining simple cron magic.
Debugging crond
You can turn up the verbosity of crond
by adding the following to this configuration file on RHEL/CentOS/Fedora based distros.
$ more crond
# Settings for the CRON daemon.
# CRONDARGS= : any extra command-line startup arguments for crond
CRONDARGS="-L 2"
The valid levels are 0, 1, or 2. To revert this file back to it's default logging level simply remove the "-L 2"
when you're done debugging the situation.
Best Answer
On a system, the only thing that is really persistent is a file. That's pretty much what you should use. Here's an solution using an init.d script.
Let's consider the following (simple) script,
/etc/init.d/myupdate
:If you activate it with
update-rc.d myupdate defaults
, thestart
action will be executed upon boot. Now, when your update script calls for a reboot:With this solution, you can divide your update script into two parts :
It'll execute the
before_reboot
code section, create a file in/var/run
, and reboot. Upon boot, the script will be called again, but since the file exists,after_reboot
will be called instead ofbefore_reboot
.Note that
update-rc.d
requires root privileges.Without using a file (from Stephen Ostermiller's comment):
If you are familiar with the
getopts
utility, you may want to use options instead of files. In the init script, call the script with:And in your script, check for options instead of files. Call your script once without the option, and init.d will call it again on boot, this time with
-r
.You'll find more information about option handling here (for short options only). I also edited my script with calls to
update-rc.d
to keep this a one-time job (from another comment).