-   Linux - General (
-   -   Can't get a cron job to run (

derzok 12-15-2007 03:59 PM

Can't get a cron job to run
So I'm a newb to cron, I've never used it before. After reading a bit online, I did the following:

ran "contrab -e" as the user I wanted to run my script as. I entered the line "*/10 * * * * /home/", saved and quit (:wq)

When I view the log file /etc/log/crontab and it showed the script running correctly:

Dec 15 16:20:01 zoklet crond[15319]: ( CMD ( /home/
Dec 15 16:30:01 zoklet crond[15389]: ( CMD ( /home/

However, it's obvious that the script hasn't been run because it hasn't changed any of the things it's supposed to (script posted below). Just in case, I tried restarting crond - didn't help. I don't think it's a problem with the script, because when I run it from the command line it works just fine. Ideas?

Run Script:

perl > out.txt

# Script connects to said gmail account, checks for new messages
# If a new messages are found, it takes the attachment (.jpg) and posts
# it in a public_html directory on the server for public viewing
# Pretty cool, eh?

use Mail::POP3Client;
use IO::Socket::SSL;
use Email::MIME::Attachment::Stripper;
use DBI;
use strict;

my $username  = 'edited'; # edit this
my $password  = 'edited';        # edit this

my $mailhost  = '';
my $port      = '995';
my $time = time();

my $pop = new Mail::POP3Client( USER    => $username,
                                PASSWORD => $password,
                                HOST    => $mailhost,
                                PORT    => $port,
                                USESSL  => 'true',
                                DEBUG    => 0,
if (($pop->Count()) < 1) {
        print "No mail at $time\n";

my $database = "edited";
$port = "3306"; # overwrites
$password = "edited"; # overwrites
$username = "edited"; # overwrites
my $dsn = "DBI:mysql:database=$database;host=localhost;port=$port";
my $dbh = DBI->connect($dsn,$username,$password);
for(my $i = 1; $i <= $pop->Count(); $i++) {
        my $message = $pop->HeadAndBody($i);

        my $stripper = Email::MIME::Attachment::Stripper->new($message);

        my $msg = $stripper->message;
        my @attachments = $stripper->attachments;
        my $filename = $attachments[0]{ 'filename' };
        my $out = "/home/" . $filename;
        open OUT, ">$out" or die "cannot open the file yo: $!";
        print OUT $attachments[0]{ 'payload' };
        close OUT;
        system("convert /home/$filename -resize 640x480 /home/$filename");
        my $q = "INSERT INTO `otg` (`date`,`filename`) VALUES ('$time','$filename')";
        my $sth = $dbh->prepare($q);


[ zok_OTG]$ ls -al
total 448
drwxrwxr-x  2  4096 Dec 15 16:55 .
drwx--x--x 24  4096 Dec 15 16:55 ..
-rw-rw-r--  1  1594 Dec 15 12:25
-rw-rw-r--  1      0 Dec 12 15:51 out.txt
-rwxrwxr-x  1    26 Dec 15 12:22 run

jailbait 12-15-2007 04:39 PM

The most likely cause of this problem is that perl may not be on cron's PATH. Try giving the full path names for the perl command and in your script.

Steve Stites

derzok 12-15-2007 04:43 PM

I just edited the file now. We'll see what happens in 6 minutes.

derzok 12-15-2007 04:51 PM

Dec 15 17:50:01 zoklet crond[16235]: ( CMD ( /home/

out.txt is still empty and the mail has yet to be downloaded, no luck :/

colucix 12-15-2007 05:21 PM

You can try to redirect standard error to standard output, otherwise if your script generates some errors you don't catch them. So you can simply add redirection to the perl commandline

perl > out.txt 2>&1
Also check the system mail (I mean that one accessed by the command mail) to see if the cron daemon sent some message (it happens when the cron job generates output or error that have not been redirected anywhere).

hbar 12-15-2007 05:34 PM

I think I know what it is. Cron is picky and usually doesn't like file extensions. Remove the ".pl" from the filename (leaving just "getmail"). Then you need to put this line (shebang) as the very first line of the file (before the comments):

#!/usr/bin/env perl -w
Also might want to ensure that the script has exec permission:

chmod +x getmail

derzok 12-15-2007 06:53 PM

I added the shebang to my perl file, removed the .pl from the end of the file name, and added 2>&1 to my run file. None of those seemed to work :/

out.txt is still empty, the script hasn't been run, there are no errors in the cron log file, and there is no mail for the users or root.

colucix 12-15-2007 07:30 PM

Unless you have not previously touched (that is created an empty) out.log, the script has run. Anyway, you can

1. verify that the cron daemon works properly (and that particular user is allowed to run cron jobs) by testing with a simple crontab, like

* * * * * /bin/echo $HOME >> $HOME/test.log
2. if previous test is ok, you can do a backup copy of the perl script, substitute it with another simple perl script that prints something out, remove the redirection to out.log (into the run script) and restore the crontab as this
*/10 * * * * /home/

3. if none of the above works, have a cup of coffee and post here again! ;)

derzok 12-15-2007 07:55 PM

The first test did work, I'm trying the second now. What does the MAILTO= line do? Will that send any error messages to my system mail? Also, will the perl script output to the console if it's run by cron? Either way, I'll sit and wait another 5 minutes to see what happens.

Edit: No output:

[ zok_OTG]$ date
Sat Dec 15 20:59:40 EST 2007
[ zok_OTG]$ date
Sat Dec 15 21:00:06 EST 2007

Edit #2: I just realized that my run script is not using an absolute path to the perl script. I'll edit that change in for any further tests.

derzok 12-15-2007 08:11 PM

Problem solved! It turned out to be the absolute path that was causing problems. That makes a lot of sense, now that I think about it. Thanks for all of your help, guys!

colucix 12-16-2007 04:00 AM

I assumed that it was not an issue, since jailbait correctly suggested the solution in post #2 and you told to have followed his advice in post #3...! Anyway, regarding the MAILTO question, here is an excerpt from "man 5 crontab":

In addition to LOGNAME, HOME, and SHELL, cron(8) will look at MAILTO if it
has any reason to send mail as a result of running commands in ``this'' crontab. If
MAILTO is defined (and non-empty), mail is sent to the user so named. If MAILTO is defined but empty (MAILTO=""), no mail will be sent. Otherwise mail is sent to the owner of the crontab.
Test it by sending output to nowhere (indeed, any output from the cron job cannot be sent to any console - if not explicitly coded in your scripts) and look at the user's system mail (or to the mail specified by the MAILTO variable). Cheers!

All times are GMT -5. The time now is 11:31 PM.