2

I have a 4 scripts to transfer database from one server to other for testing purpose. These scripts execute automatically in the night. When I call the scripts manually, I get no error, but without running them manually, I cannot see any data being transferred.

Server 1 :

ps -ef | grep cron
root      2350     1  0 Apr23 ?        00:00:26 /usr/sbin/cron
root     14293  9533  0 10:52 pts/4    00:00:00 grep cron

Server 2 :

ps -ef | grep cron
root     11269  8661  0 10:52 pts/1    00:00:00 grep cron
root     21726     1  0 Jan30 ?        00:00:31 /usr/sbin/cron

Server 1

crontab -e
# m h  dom mon dow   command
0 3 * * * /home/deploy/scripts/clearzip.sh
19 2 * * * /media/attachment/send_db.sh

send_db.sh

#! /bin/bash
pg_dump -C "DB_NAME" | bzip2 | sshpass -v ssh user@server2 "bunzip2 | psql "DB_NAME""
pg_dump -C "DB2" | bzip2 | sshpass -v ssh user@server2 "bunzip2 | psql "DB2""

Server2 :

# m h  dom mon dow   command
12 2 * * * ./home/postgres/stop_services.sh
17 2 * * * ./home/postgres/dropdb.sh
55 5 * * * ./home/postgres/start_services.sh

stop_services.sh :

#! /bin/bash
echo > >(tee -i /home/deploy/logfile.txt)
sh /home/deploy/tomcat7/bin/catalina.sh stop
killall java
killall screen

dropdb.sh

su -c "psql -c 'drop database "DB1";'" -s /bin/sh postgres
su -c "psql -c 'create database "DB1";'" -s /bin/sh postgres
su -c "psql -c 'drop database "DB2";'" -s /bin/sh postgres
su -c "psql -c 'create database "DB2";'" -s /bin/sh postgres

What might I be doing wrong? Any ideas?

Update

Errors in log file

could not change directory to "/root": Permission denied
could not change directory to "/root": Permission denied
could not change directory to "/root": Permission denied
could not change directory to "/root": Permission denied
/home/postgres/start_services.sh: line 5: service: command not found
/home/postgres/start_services.sh: line 6: service: command not found
  • cron should send you a mail if any error occured, have you check root's mail ? /var/log/messages ? – Archemar Sep 22 '17 at 9:11
  • @Archemar : On both servers, no mail for root... – We are Borg Sep 22 '17 at 9:12
  • Don't use su in crontab - use that users crontab instead sudo contrab -u postgres -e or even better use /etc/cron.d/<cronfile> where you can specify the user before the command ie 12 2 * * * root /home/postgres/stop_services.sh (also, why do you have a . in front of /home ?) – Michael Daffin Sep 22 '17 at 9:15
  • @MichaelDaffin : Those dots might be a problem. Before the scripts were in /root, then I moved them, forgot about those dots. The script is executed as root, should I still use sudo under that condition? Thanks – We are Borg Sep 22 '17 at 9:19
  • You should also use passwordless ssh keys instead of sshpass - my guess is that the scripts are blocking/chocking on expecting stdin to be a terminal, which is not true for cron jobs. – Michael Daffin Sep 22 '17 at 9:19
3

I see two problems:

  1. You are running things that need root privilege but are running them as a regular user.

  2. You are using command names without their full PATH and therefore, the session opened by cron doesn't know where to find them.

To fix 1., don't use crontab -e and instead edit /etc/crontab or, even simpler, run sudo crontab -e to add it to root's crontab. Then, edit your dropdb.sh and remove the su (the script will now be launched by root, so no need for su).

To fix 2, the simplest approach would be to define the PATH in the crontab. It should look like this:

PATH=/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin
# m h  dom mon dow   command
12 2 * * * ./home/postgres/stop_services.sh
17 2 * * * ./home/postgres/dropdb.sh
55 5 * * * ./home/postgres/start_services.sh

Alternatively, edit your scripts and make sure they all use absolute paths (so /usr/sbin/service instead of service).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.