[conspire] Linux cron help

[Rick Moen]

Quoting Bill Lazar (bill at billsaysthis.com):

> I'm trying to set up cron to run a little PHP script once a night. I use a
> shared server and included the command in a text file, then ran crontab
> filename to activate it. Here is the single line I used:
> 
> 11 1 * * * blazar php www/utils/cronjobs/impdates_checker.php
> 
> The file is in the 'root' directory of my user space on a hosted/service
> provider server. I tested the PHP script that should be called separately
> and now it works.
> 
> I also tried extending the path/to/script value to
> /home/blazar/www/utils/cronjobs/impdates_checker.php with no difference in
> result.
> 
> Any help would be appreciated.

Not intended to sound like I'm complaining, but I was a little confused
by the above:  You kinda-sorta state what you did, but only in narrative
form.  Just a suggestion:  Assume tech people are all from Missouri
(figuratively speaking).  That is, you have to _show them_.  ;->

You may have meant you did something like this:

$ cd /home/blazar
$ cat impdates-cronjob
11 1 * * * blazar php www/utils/cronjobs/impdates_checker.php
$ crontab impdates-cronjob

...but I have to admit I'm guessing, a bit.

(You don't _have to_ "show them", but it does make it easier for people
to be sure they understand your situation.[1])


In addition, I wasn't really exactly clear on what problem you were
trying to solve, i.e., you didn't quite come out and state what the
symptom is.  It's probably:  "Despite my doing the above, and my
expectation that my job would run at 1:11 am every night, I'm pretty
sure it doesn't run because [reason foo]."


I'm often a little shaky on personal crontabs, because the edit syntax
is a little peculiar, and because I usually end up using the system-wide
ones -- so please forgive a few paragraphs of review, as I try to
remember this stuff.  (Explanation assumes use of the standard Vixie
cron, as opposed to any more-exotic ones.)


Each user _can_ have his own personal crontab, which gets stored in the
/var/spool/cron/crontabs directory if it exists.  Those files are _not_
supposed to be edited directly; instead, you do "crontab -e".  Without
the "-e" and with just a filename, e.g., "crontab impdates-cronjob"
overwrites your existing crontab using the contents of the specified
file.

"crontab -" does the same using standard input as the source, rather
than a named file.  (This is a common meaning for "-".)

Regardless of _how_ you edit your personal crontab, it's a really,
really good idea to double-check your work using "crontab -l" (list the
contents to screen).


But anyway, I _do_ see one problem:  "blazar" (obviously your username).
That isn't part of the syntax for a _personal_ crontab.  For a
system-wide crontab (e.g., /etc/crontab), it's necessary to specify for
each task what username to run it as.  For user blazar's personal
crontab, by contrast, it's flippin' obvious which user to run it as:
blazar.  So, there is no such field.

Fields for a personal crontab are:
minute  hour  day-of-month  month  day-of-week  command-and-parameters-to-run

An asterisk for any of the frequency fields means "all" (or "first
through last").  

For further details (including the system-wide variant where you specify
the username), see "man 5 crontab".

By the way, since your intended command string is evidently "php
www/utils/cronjobs/impdates_checker.php", make very sure that the exact
same sequence works if you type it at the command line.  That's a good
rule of thumb for indirectly called commands, generally.

And you might try a simple test-case, first, e.g., running 
  echo "hello"
a few minutes from now -- before just setting something up for next 1:11
am and hoping for the best.  ;->


[1] This is one reason why tech people ask querents to do particular
sequences of commands from _the command line_ instead of using graphical
tools to get diagnostic information:  It makes it very easy to
copy-and-paste _exact_ actions to be performed directly onto a command
line, and to copy-and-paste to reply e-mails the exact information
returned from them.

If I ask a querent to type "dig linuxmafia.com +short" and send me back
the exact command transcript, showing that command and the reply, it
tells me a lot more about the user's local DNS situation -- and with
greater certainty -- than if he gives me a narrative about his Web
browser.