[SOLVED] Crontab issue

[Don B. Cilly]

Neon 5.17.
My crontab has two entries:

46 */2 * * * /home/not/.xplanetFX/xeric.sh >>~/Documents/cron.log
42 1-23/2 * * * /home/not/.xplanetFX/xcloud.sh >>~/Documents/cron.log

(they're little scripts to fetch and convert cloud images for xplanetFX).

The first one, set to run at 46 minutes past the hour every even hour, runs just fine.
The second one, set to run at 42 minutes past the hour every odd hour, never runs.

If I run it "manually" in a console, copy-pasting it exactly as it is, it runs just fine.
It just won't cron.
I can't see anything wrong with the crontab entry, though. Can you?

[Snowhog]

From the crontab manual:

Step values can be used in conjunction with ranges. Following a range with "/<number>" specifies skips of the number's value through
the range. For example, "0-23/2" can be used in the 'hours' field to
specify command execution for every other hour (the alternative in
the V7 standard is "0,2,4,6,8,10,12,14,16,18,20,22"). Step values
are also permitted after an asterisk, so if specifying a job to be run every two hours, you can use "*/2".

Change your hours value to 0-23/2

(ref: http://man7.org/linux/man-pages/man5/crontab.5.html)

[Don B. Cilly]

Hmm.1-23/2 is the suggested way to set it to odd hours - as starting at 0 would run it at even ones, wouldn't it?
And I want them to run at different hours, so I get different clouds - and see the difference.

Still, I changed it to 42 1,3,5,7,9,11,13,15,17,19,21,23 * * *, and it still does not run.

[jlittle]

crontab jobs are treacherous because they run without a normal login occurring. The fact that the command works at a shell prompt is not conclusive that it will work in a crontab entry. I think the entry works but the script fails.

With the proviso that I haven't used cron for many, many years, to diagnose this I would add a layer of indirection with a script that runs the script, so that you can do stuff like dump out the environment, check what shell is running, and capture errors.

[Don B. Cilly]

Something like

#!bin/bash
/home/me/runthebleedinthingy.sh

which runthebleedinthingy.sh
runs-the-command >>~/Documents/wtf.log?



I've downloaded hcron. I'll check it tomorrow and see if it works.

[jlittle]

(I said it was a long time ago.)

In a konsole, run mail. That might tell you what's going on. Errors get mailed to you, using the ancient mail mechanism.
[Edit] That command is awful. Avoid it if you can; but if you do run it, "x" or "exit" quits without saving, and "q" or "quit" saves changes and exits. The command to list out the messages and their status is "h" and to get command help it's "l".

[Don B. Cilly]

I will. But...

~$ mail
Command 'mail' not found, but can be installed with:
sudo apt install mailutils

...for the moment... :·/

[jlittle]

I try to run the commands I post about. In this case, I tripped in to a frustrating rabbit hole of illogic just trying to delete the messages I got cron to generate.

I imagine kmail can access the unix mail in /var/mail/$USER, but on my eoan akonadi has got borked and kmail won't run. If you do want to work with cron I suggest installing mutt rather than mailutils. As the author of mutt put it, all mail clients suck, mutt just sucks less.

[Don B. Cilly]

So, after a full day of headbanging, I found the fault.
It wasn't the crontab syntax, it was cron's "ignorance".
Turns out that one of the commands used in the script was in my $PATH, but not in cron's.
So I just had to change
project -i mollweide -f latest_moll.ppm > cloudFX.ppm
to
~/.local/bin/project -i mollweide -f latest_moll.ppm > cloudFX.ppm
and the script runs just fine.



[P.S.] Obviously, setting the $PATH in /etc/crontab to the same as your user would work even better :·)