I have the following cron that checks if my Neo4J DB is running and if it's down, it shuts down the Node.Js app, then restarts the db and then starts the app again. The second line is the backup script.
* * * * * /home/noduslabs/neo4j-community-2.0.1/bin/neo4j status || /home/noduslabs/webapps/infranodus/bin/forever stopall && /home/noduslabs/webapps/infranodus/bin/forever start $HOME/webapps/infranodus/infranodus/app.js && /home/noduslabs/neo4j-community-2.0.1/bin/neo4j start
10 14 * * * ~/webapps/infranodus/bin/backup
When I run the code myself from the shell, such as
/home/noduslabs/neo4j-community-2.0.1/bin/neo4j status || /home/noduslabs/webapps/infranodus/bin/forever stopall && /home/noduslabs/webapps/infranodus/bin/forever start $HOME/webapps/infranodus/infranodus/app.js && /home/noduslabs/neo4j-community-2.0.1/bin/neo4j start
It does everything well.
But the cron doesn't do that check every minute and doesn't relaunch anything...
PS When I do crontab -l it lists the above and I edit it using EDITOR=nano crontab -e - just in case that matters...
Any idea why?
Thanks!
The problem was that Neo4J is a Java program and it was not running from cron correctly – not the same environment variables.
What I did was to change cron so that it runs a shell script
* * * * * ~/webapps/infranodus/bin/checkdb
and in side that checkdb script I have:
#!/bin/bash -l
/home/noduslabs/neo4j-community-2.0.1/bin/neo4j start
which simply attempts to restart the DB (if it started already it will simply not start because it's the same process)
So that's a workaround and the first line - to use bash shell is very important - so it stays with the same params.
Related
I am trying to run a node script on an AWS Ubuntu server. When I log into the Ubuntu server from my terminal and run my script with the command "node dacDev.js" it works just fine. The script writes to a log file in another folder. I want to run this with a cron command on AWS, but it won't run. Here is what my cron job says.
"* * * * * /home/ubuntu/.nvm/versions/node/v13.14.0/bin/node /home/ubuntu/getmyteatime/cronjob.sh"
The file cronjob.sh contains the absolute path of the node script. It reads:
node /home/ubuntu/getmyteatime/dacDev.js
Nothing runs. What am I doing wrong?
For the node, you also need an absolute path to run any.js file. This is achievable but rather than running with node try to write a script and do the following:
echo $PATH # /path/to/env
which npm # /path/to/npm
Paste below lines when the command crontab -e is executed.
PATH=/path/to/env
* * * * * cd /path/to/app && path/to/npm run script >>/tmp/crontab.log 2>&1
>>/tmp/crontab.log 2>&1 -- means, it will log the result to this path for debugging purposes.
I am trying to use a docker container based on an Alpine image to run a scheduled cron job, following this tutorial, but after printing the statement in my startup script, the container just exits, without running my other script.
My docker-compose service is configured as follows:
cron:
image: alpine:3.11
command: /usr/local/startup.sh && crond -f -l 8
volumes:
- ./cron_tasks_folder/1min:/etc/periodic/1min/:ro
- ./cron_tasks_folder/15min:/etc/periodic/15min/:ro
- ./cron_tasks_folder/hourly:/etc/periodic/hourly/:ro
- ./scripts/startup.sh:/usr/local/startup.sh:ro
So it runs an initial script called startup.sh and then starts the cron daemon. The startup.sh script contains the following:
#!/bin/sh
echo "Starting startup.sh.."
echo "* * * * * run-parts /etc/periodic/1min" >> /etc/crontabs/root
crontab -l
sleep 300
I dropped a sleep command in there just so I could launch an interactive shell on the container and make sure everything inside it looks good. The script creates another folder for 1min scripts. I have added a test script in there, and I can verify it's there:
/etc/periodic/1min # ls -a
. .. testScript
The script is executable:
/etc/periodic/1min # ls -l testScript
-rwxr-xr-x 1 root root 31 Jul 30 01:51 testScript
And testScript is just an echo statement to make sure it's working first:
echo "The donkey is in charge"
And looking at the root file in etc/crontabs, I see the following (I've re-run the container several times, and each time it's creating a new 1min folder, which is unnecessary, but I think not the problem here):
# do daily/weekly/monthly maintenance
# min hour day month weekday command
*/15 * * * * run-parts /etc/periodic/15min
0 * * * * run-parts /etc/periodic/hourly
0 2 * * * run-parts /etc/periodic/daily
0 3 * * 6 run-parts /etc/periodic/weekly
0 5 1 * * run-parts /etc/periodic/monthly
* * * * * run-parts /etc/periodic/1min
* * * * * run-parts /etc/periodic/1min
* * * * * run-parts /etc/periodic/1min
* * * * * run-parts /etc/periodic/1min
* * * * * run-parts /etc/periodic/1min
The echo statement in testScript is never printed to my terminal, and the container exits with exit code 0 shortly after starting. I want to print this statement every minute... what am I missing?
In the docker compose file you have
command: /usr/local/startup.sh && crond -f -l 8
The intention is to run as a shell command, but it's not at all clear from the question that's what's going to happen; that depends on your ENTRYPOINT. Since it's defined with [] brackets, not additional shell will be provided. The command value will be passed as arguments to the ENTRYPOINT.
Assuming that will become a shell command, && in the shell runs the left hand side, and if that succeeds, then runs the right hand side. So startup.sh needs to complete before crond is executed. startup.sh ends with
sleep 300
crond is invoked only after that 300 seconds.
In either case, crond is either not invoked at all, or sleep has not been completing. The comments show that an error starting crond was discovered.
Using an entrypoint such as this is standard practice to configure the environment before, or provide runtime parameters when, invoking the main executable. To do it right, you should make sure to use exec to run the main executable so that it receives the signals that would otherwise go to the bash shell running the entrypoint script.
So at the end of startup.sh:
exec crond -f -l 8
Will replace the shell running startup.sh with crond, so that crond receives all signals (at this point the shell is gone). It's subtle but important!
In general, keep the invocation of the application as simple as possible. Case in point, your execution process was split between entrypoint, command, and startup script, with no clear interface between them. You wouldn't have gotten hung up on the invocation if you had put crond directly into the Dockerfile and left it at that. Sometimes arguments must be provided at runtime, but environment variables - which have names, not just positions - are often preferred. This keeps invocations simple and debugging straightforward. But, when that doesn't work, a shell script entrypoint is a great solution - just make sure to exec your final process!
I'm trying to run a cronjob to start and stop a server under a non-sudo user. I've tried asking others and doing what I saw from looking on google before asking here, but I'm still stuck.
Here's what's in my crontab for the server user:
* * * * * /home/server/startup/stop.sh
* * * * * /home/server/startup/start.sh
Here is what is in my stop.sh script:
#! /bin/sh
screen -r server -X quit
Everything runs normally if I run it using sh, and I only encounter a problem when using cron.
From what I see there could be 2 possible problems:
If the lines you are running in crontab are (and only those):
home/server/startup/stop.sh
home/server/startup/start.sh
then you are missing the time part of the line. If you want to run your program only once on boot you can run:
#reboot home/server/startup/start.sh
You are not giving the full path to your program (possibly you are just missing a / in the begging). Try running
* * * * * /home/server/startup/start.sh
or
#reboot /home/server/startup/start.sh
If these don't work I recommend you try the following to troubleshoot the issue:
Run the command using sh in the cron:
* * * * * /bin/sh /home/server/startup/start.sh
Try redirecting the stdout and stderr of your command to a file and see if any errors occur
I want to automatically start a program if it crashes (check if the process exists, if not, restart it), so using crontab is a simple solution, but
I creatd a simple crontab task using crontab -e or in /etc/crontab file like this:
* * * * * /usr/bin/gnome-terminal
it doesn't work, it never launches gnome-terminal, I can see it executes the task in /var/log/syslog (Ubuntu) or /var/log/cron (CentOS), the gnome-terminal never comes up.
if you say since gnome-terminal is a gui program, then, this script to create bluetooth service won't work either :
using crontab -e or /etc/crontab:
* * * * * /home/username/run-bt
run-bt:
#!/bin/sh
# find bt pid
/usr/bin/pgrep bluetoothd
# if not running
if [ $? -ne 0 ]
then
/usr/sbin/service bluetooth restart
fi⏎
I already made the run-bt script executable, but bluetooth service won't start even if I stop the bluetooth service manually.
but this:
* * * * * /bin/ls > /tmp/ls.output
works as expected.
What's wrong?
Actually crontab does not load all the environment variables of the current user it runs for, just a few of them.
Maybe some of those environment variables are required by the scripts you try to run?
I'm running RHEL and I'm trying to set up a cron job to run a shell script every 5 minutes.
Following the directions here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Automating_System_Tasks.html#s2-configuring-cron-jobs
I have service crond start and chkconfig crond on. Then I edited /etc/crontab and added:
*/5 * * * * my-user /path/to/shell.sh
I did a chmod +x shell.sh. And I made sure to add a new line character at the end.
I'm expecting it to run every 5 minutes but it never executes.
What am I doing wrong?
Simply try to add the cronjob entry and check the script is working fine or not by taking the viewable output in the script.
echo "test time - $(date)" > script.sh
chmod +x script.sh
crontab -e
Then enter the cronjob as below,
*/5 * * * * sh /path/to/script.sh > /path/to/log.file
Check if the log is writing correctly. If its fine, better cross check the script that you are trying to execute via cron. Otherwise it will be a cron issue.