Perhaps you have a websites on a server on some Linux distro / FreeBSD / AIX / HP-UX / Sun OS that uses Vixie-cron cron jobs to run / respawn dead php / python perl scripts etc. that do stuff on the server every lets say 30 minutes an hour or even every 12 / 24 hours in the background.
But sometimes due to server or Linux kernel upgrades you need to reboot the server with reboot command or shutdown -r now right in the minutes the scripts were supposed to run and do a database backup / synchronize some data with a remote MySQL with replication configured or do some site maintenance job such as clearing old Messages / Spam / data log file records.
Of course one possible workaround to that is to add the non-root user scripts in question to /etc/rc.local to run on every server boot, but that fix requires a root access and very often developers did not have that, neither sysadmins are willing to bother add a user sudo-ed scripts e.g. add (sudo -u whateveruser "/path/to/script") to /etc/rc.local.
Run custom user script after reboot the cron way
Happily there is ctually a better cron way to do that by telling crond to execute a cronjob during boot and assuming the non-admin user on the Linux has access to shell and access to using cron jobs by using @reboot cron direcive.
Here is few examples on how to run a re-run cron job on start up:
linux:~$ crontab -e
Some editor as nano or vim will open listing all your previous set system jobs to add scripts phpjob.php
@reboot /user/dir/path/to/phpjob
@reboot /path/to/shell_script
@reboot /path/to/linux-command
That's pretty shitty situation but thanksfully remote access of website username with SSH will be enough to set the right cron activity (of course this can't be made for servers that are missing crond service running.
The scripts set in cron job that way will respawn right after the OS system had booted and there will be no need for them to wait the next hour to execute configured data synch.
For more on how to run a tiny script respawn every second using a single cron job check out my previous article How to set a crontab to execute commands on a seconds time interval on GNU / Linux and FreeBSD.
Historically it is interestingly to mention that in times before systemd appeared in modern Linux distributions,
a cool thack to run a script that had to be respawned every second after boot for a privileged user was to use /etc/inittab (no longer available in most all non System V Linux distrubutions in 2018), to do so
if you happen to still administer some old Linux servers CentOS 7 etc. you and you need to add a custom script to run and respawn all the time by including a line in /etc/inittab (again assuming a System V Linux is on remote machine):
mysvc:235:respawn:/home/me/bin/my_service_starter_script
Putting a service to respawn in that way via inittab uses init (process) and the kernel and keeps re-running it.
Note:
If a command fails when it starts, and init is configured to restart it, it will use a lot of system resources: init starts it, it fails, init starts it, it fails, init starts it, it fails, and so on, ad infinitum. To prevent this, init will keep track of how often it restarts a command, and if the frequency grows to high, it will delay for five minutes before restarting again.If the kernel
Using inittab should always be tested on a testbed before adding to remote server, note that if the script is using a lot of memory and keeps crashing it can easily leave out the kernel without memory and the system is about to get errors like:
process respawning too fast
Another useful thing if you have doubts that the script might be crashing is to use something like monit to monitor the script (assuming the script does provide some kind of tcp / udp connection on port) and report you via email / sms about issues with crashing script.
If you hear monit the first time I recommend you read my previous article Monitoring and restart server services (Apache, Mysql, Bind) with Monit to prevent server downtimes.
