Using Zip with crontab

[zaradell]

Good afternoon to you all

I really need help...

I´m having a problem using ZIP with crontab. For some reason the cronjob it not being made as specified in crontab.When i run the command in CLI it works fine. The problem is just when i try to run it in crontab:

30 12 20 * * root /usr/bin/zip -r /Copy/$(date +%Y_%m_%d).zip /Backups_Tools_Automatic/Nagios/*


I´ve tried creating a script .sh and run it with crontab but no luck. I´ve tried to remove "root" from the begining of the line, but nothing. I´ve also tried to replace $(date +%Y_%m_%d).zip with name.zip but also nothing.

Is there anything specific I have to do, so that ZIP works with Crontab?

I´d really apreciate some help.

Thkx

 

[elgrandeperro]

Then it just creates it as /tmp/2008_04_21 with no .zip. It is not a requirement of writing that the file end in .zip, it is still a zip image.

BTW, it is:
* * * * * root /usr/bin/zip -rq /tmp/$(date +\%Y_\%m_\%d) /var/run/*.pid


Also, if you change /etc/crontab you probably need to cycle crond. If you use "crontab -l", then you don't need to cycle crond, it knows a user is making a change. If you install the scripts in /etc/cron.(daily/weekly/monthl(, then I don't think you need to cycle crond.

Personally, I would use the crontab -l (without the root) because that is where custom stuff should go, and a Linux upgrade is probably going to overwrite /etc/crontab.

 

[Annihilannic]

Typo... crontab -e I think you meant.

Annihilannic.

 

[KenCunningham]

...But safer to use crontab -l > newcron, edit newcron and then crontab newcron to activate it.

I want to be good, is that not enough?

 

[zaradell]

Ok...so I´ve finally made it. It was a really stupid problem.

First, my version of crontab simply won´t run zip. So I´ve created a sh script.

Then I ran the script in crontab...it didn´t work, until I did a service crond restart.

Strangely enough, even with crontab -e, my crontab won´t restart automatically. I have to set the cront line to run the script in crontab, write it, and then restart crond service. Only then, it will work

 

[Annihilannic]

Out of curiosity, when you were testing this were you setting the job up to run in the very near future so that you wouldn't have to wait long to see the results of your test?

I've noticed that if you set up a job to run in a minute's time (or less) that it won't run, because crond seems to wake up once a minute, run any jobs it's scheduled to run at that time, and then check for updated crontabs. So if you are testing that way, make sure you schedule it for at least a couple of minutes from now.

Annihilannic.

 

[elgrandeperro]

Annihilannic, good point. I believe the way cron builds the in-memory hashes, it is always reading a minute (at least) behind, like it executes the list then rebuilds it or it skips the new additions.

Yes, I use "crontab -l > file" then vi it. The reason was that I one time I ran out of space and could not write the file, and the other time the system crashed and the crontab could not be recovered. 2 restores is 2 too many.

Also with the code in a script, you can change it without twiddling crontab, which is both a blessing and a curse because anyone with write access to that file can take over your system.

 

[zaradell]

Annihilannic

I think you´re right. When I was making my cronjob tests, I´ve always made it with a window of 30 secs, 1 minute, max 1,50min

I thought that when you wrote the crontab it would automatically restart it´s service.

But...not!

But besides that, I also think it has something to do with the version of my IOS: Fedora 4. It´s kinda old, and I suspect the crontab has never been updated. And since it´s an equipament which is now in production in my company, I´m not allowed to update it.

Oh well...at least it´s working. I´m still curious, though, on why crontab won´t recognize zip, or gzip, or tar. At least my version won´t...

 

[elgrandeperro]

The problem I saw was that you didn't esapce the % signs.
(and that the sixth field is part of /etc/crontab but not part of the generic users's crontab).

I did some testing. Using just %, crontab does not even invoke the command line because it gets confused. With the \%, it works fine..

I used this script:

/tmp/doit
#!/bin/sh
echo $0 $2 $3 $4

then did the crontab in two ways:

* * * * * /tmp/doit /usr/bin/zip -r /Copy/$(date +%Y_%m_%d).zip /Backups_Tools_Automatic/Nagios/ > /tmp/doit.out

and

* * * * * /tmp/doit /usr/bin/zip -r /Copy/$(date +\%Y_\%m_\%d).zip /Backups_Tools_Automatic/Nagios/ > /tmp/doit.out

The output of the first (failed) gets mailed to me:

/bin/sh: -c: line 0: unexpected EOF while looking for matching `)'
/bin/sh: -c: line 1: syntax error: unexpected end of file

(hmmm, I was wrong. It looks like it uses the /bin/sh -c to interpret the line).

The second works, gives me in /tmp/doit.out:

/tmp/doit /usr/bin/zip -r /Copy/2008_04_23.zip /Backups_Tools_Automatic/Nagios/

( I didn't put the * to avoid the non-match of args)

The point is, it isn't zip, it is the syntax error in cron. You aren't even getting to the point of calling gzip.

 

[zaradell]

elgrandeperro

---------------------------------------------------------
I don´t think there´s a problem with the date path. I´ve tried to replace the date string with a name and nothing:

30 12 20 * * root /usr/bin/zip -r /Copy/name.zip /Backups_Tools_Automatic/Nagios/*
--------------------------------------------------------

I´ve tried replacing the data string with name.zip and it didn´t work.

And as for the * I have other cronjobs such as:

30 20 * * 6 root mv /home/ccmavl/* /mnt/ccmshare/ccmavl/

and I have no problem moving those files, so I don´t think it´s a syntax problem.

 

[elgrandeperro]

There are in /etc/crontab?
Read root's mail to see why it fails,
mailx -f /var/mail/root

 

[zaradell]

Yes, they are set in /etc/crontab.

As for /var/mail/root I did check it. It´s kinda weird, there´s no entry of the zip cronjob. It´s like it wasn´t invoked...like the line isn´t even there.

 

[elgrandeperro]

grep cron /etc/syslog.conf

Mine is redhat, so it reads:
# Log cron stuff
cron.* var/log/cron

You should see the execution of your command logged there.

Apr 24 14:12:01 mymachine crond[26866]: (root) CMD (/usr/bin/zip -r /tmp/mine.zip /tmp/ziptest/* > /tmp/doit.out)
Apr 24 14:13:01 mymachine crond[26870]: (root) CMD (/usr/bin/zip -r /tmp/mine.zip /tmp/ziptest/* > /tmp/doit.out)