Our system is on AWS. Debian EC2 instance. RDS postgres instance.
when I log into the "admin" account pd_dump works.
$ whom
admin
$pd_dump
[it works...]
then I crontab -e in order to create a test backup event.
*/2 * * * * /home/admin/storage/db_backup.sh
and indeed, it runs every 2 minutes.
in db_backup.sh I have:
pg_dump > dbbackup.txt
the script and the folder I am running at belong to "admin".
The dbbackup.txt is always generated with a zero size.
why is that?
I found out what the culprit was. Since I'm ran in the context of admin but in cron, my environment strings were not set.
setting this at the head of my db_backup.sh resolved this:
export PGPASSWORD=<value>
export PGHOST=<value>
export PGDATABASE=<value>
export PGUSER=<value>
We can only guess here, but I have a suggestion. Try redirecting ALL output (including stderr) to the file to see if it gives you some information.
in your /home/admin/storage/db_backup.sh add 2>&1:
pg_dump > dbbackup.txt 2>&1
you may also use this and redirect your cron line in case your .sh file has some problems:
*/2 * * * * /home/admin/storage/db_backup.sh >> /home/admin/cron_log.txt 2>&1
EDIT: just noticed you post an answer already. Buy if you'll have time, try removing exports and see if you can get some errors in logs that may help.
According to my mac, the zero dump files were caused because crontab couldn't understand pg_dump.
Instead, I did the following. FYI I use connection string URI.
But what's important is the full path I set to the pg_dump
/Library/PostgreSQL/13/bin/pg_dump --dbname=postgresql://admin:D%40t%40sc13nc3#localhost:5432/digitaldairy | gzip > test1232323.gz
Related
I have configured the modern authentication for O365 using App::wsgetmail module for RT, everything works fine when I run the the wsgetmail --config=config1.json via terminal it can access the email's inbox and create the ticket in RT and mark the email as read but when I am trying to use the crontab to do the same work periodically getting no result.
the corntab works with other cornjobs that I have for other tasks and only it is not working with wsgetmail.
the crontab looks like this:
*/1 * * * * wsgetmail --config=/path_to_config_directory/config1.json
Note:
I am using RT4
The config1.json file is executable
I am using root user for configurations
There is no any error in the logs
Any idea about this issue that I am facing with?
I have finally resolved the issue and posting the answer here for others that may face with same issue.
The crontab and terminal are two different environments, the wsgetmail perl module command is recognizable for terminal but to make it recognizable for corntab we have to add the full path to the module (wsgetmail) in the crontab.
*/1 * * * * /usr/local/bin/wsgetmail --config=/path_to_config_directory/config1.json
or we can create a shell script and call the script in crontab.
in this case test.sh will looks like this:
#!/bin/bash
/usr/local/bin/wsgetmail --config=account01.json
/usr/local/bin/wsgetmail --config=account02.json
I want to use cron for execute a script periodically. I want to try a simple script first but it does not work.
This is my script (scritp.sh) which permission are 700:
#!/bin/sh
clear
echo "Hello!"
mkdir Hello
And this is the crontab file when I edit it with the command crontab -e:
SHELL=/bin/sh
* * * * * /home/padro/Documents/script.sh
EDIT:
I have that script on /home/padro/Documents folder. What I do after it is execute the command crontab -e for modify the cron file. In this file I put the shell that I want SHELL=/bin/sh and also the cron schedule expression * * * * * /home/padro/Documents/script.sh. This schedule teorically run the script every minute. Finally I save the file and when a minute passes I can't see the echo of the script on the terminal.
EDIT2:
I have added mkdir hello, because I don't know if the echo of the script is shown on the terminal. But the hello directory is never created.
Any output generated by a program called from cron will by default be emailed to the user owning the crontab (assuming local delivery of mail messages is possible). So I'd suggest that you look in your inbox on the local machine.
To save the output into a file, use a redirection in the crontab, or arrange for the script to write its output to a file.
Jobs started by cron does not run with a terminal, so you should not expect to see your terminal being cleared every minute by running this script through cron.
The Hello folder should have been created in the working directory used by the script (possibly your home directory). To make absolutely sure you know where the script's working directory is, use cd in the script to move to the correct location.
I do not have enough reputation to add comment.
My humble comment would be.
Is the cron file you mentioned via root?
cos chmod 700 a file would be only be executed by owner.
If you are using redhat linux, the user account you use on the first log in is user rights NOT root.
Reference link to a cheat sheet.
su - root
system will prompt root password
crontab -e
* * * * * /home/padro/Documents/script.sh
You can even run a test script, which I did encounter the similar situation as you when I first learnt scripting into your crontab-
* * * * * date > export/home/padro/Documents/testing.txt
If you could, restart the server.
Check if your directory is correct using the command
pwd in linux/unix.
I hope my comment based on my recent learning have helped you.
Edit 1: Remove clear in your script. Thanks...
Edit 2: I believe your Hello folder is created at the core of the root folder try looking for it... or the home directory of the user...
I've created the file crontester on /etc/cron.d with this line on it:
* * * * * /usr/bin/flock -n /tmp/fcj.lockfile touch /tmp/test.txt
That should be running every minute.
But I dont see the /tmp/test.txt file being created, so the cron is not working correctly.
What I'm doing wrong? Do I've to create the /tmp/fcj.lockfile, if I've to do this, do I have to create it empty?
Thanks a lot.
The command runs fine on my machine, so the cronjob is probably not set up properly. man cron discourages creating /etc/cron.d/ files:
Like /etc/crontab, the files in the /etc/cron.d directory are monitored for changes. In general, the system administrator should not use /etc/cron.d/, but use the standard system crontab /etc/crontab.
Try creating the cronjob using crontab -e and see if it works
I am trying to to run a cronjob of a script on an EC2 Instance but it's simply not working
The way I am running it right now is
15 * * * * root /home/ec2-user s3_upload.sh TestBucket
I wrote this when I did crontab -e
Right now I am in this directory /home/ec2-user/ so I don't know if maybe that has something to do with why it's not running.
I just don't understand this whole cron thing and how permissions work.
Any help is greatly appreciated!
You can't specify a username in a user's crontab, only in /etc/crontab.
You can't specify a directory in any form of crontab. To change directory, use cd.
The environment is not the same. If you e.g. set PATH in .bashrc, these will not be automatically included, so it's safest to use full paths.
As root (assuming you want to run this as root and not ec2-user or something), run crontab -e and add
15 * * * * cd /home/ec2-user && /full/path/to/s3_upload.sh TestBucket
Make sure you can copy-paste the command in a root terminal and get it working, and read root's mail afterwards to see the command's output with possible error messages. If it still doesn't work, make sure you have these errors available.
I have a problem running a cronjob. No experience with it, so probably overseeing something nooby. The following script works like a charm (all old filters are deleted from db) when run from the shell:
dude#linux:~> /usr/bin/env /home/dude/RubyOnRails/myproject/script/rails runner /home/dude/RubyOnRails/myproject/script/delete_old_filters.rb
I made the script executable with chmod. Now I want this to run regularly using a cronjob:
dude#linux:~> crontab -e
This file was empty, and I placed this on a single line:
* * * * * /usr/bin/env /home/dude/RubyOnRails/myproject/script/rails runner /home/dude/RubyOnRails/myproject/script/delete_old_filters.rb
I expect the script to run every minute, but nothing happens. In /etc/cron.deny, only 'guest' is mentioned, and /etc/allow does not exist. Restarting my system did not help as well.
The crontab seems to be updated proberly:
dude#linux:~> crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.f9Et2M installed on Thu May 3 14:04:47 2012)
# (Cronie version 4.2)
* * * * * /usr/bin/env /home/dude/RubyOnRails/myproject/script/rails runner /home/dude/RubyOnRails/myproject/script/delete_old_filters.rb
But I expected here a bit as well:
dude#linux:~> atq
dude#linux:~>
The cronjob does something. Every minute an entry is added to /var/log/cron.log:
2012-05-03T15:27:01+02:00 linux /USR/SBIN/CRON[5276]: (dude) CMD (/usr/bin/env /home/dude/RubyOnRails/myproject/script/rails runner /home/dude/RubyOnRails/myproject/script/delete_old_filters.rb)
The problem is, that the job is not executed. It should remove some records from the database, but it doesn't. Running the same script manually does the trick.
Anyone seeing the (perhaps trivial) thing that I missed?
Perhaps this will help, using the brackets.
* * * * * ( colon separated commands-to-execute )
Check it.