crontab does not work?

[cazz]

Have a little strange problem

I have a python file that write to a textfile.
I run that from a bash file (I going to have some more python files to run)
and I have run

sudo chmod +x kor.sh

so when I run it

./kor.sh

I can see it write to the textfile

but nothing happend when I trying with crontab?

I run

crontab -e

and inside it I have

Code: Select all

*/5 * * * * /home/pi/temp/kor.sh >/dev/null 2>&1

I want to run "kor.sh" every 5 minute.
But nothing happend?

What I have done wrong?

[Curt Timmerman]

Remove the output redirection and you will probably get an email indicating the problem

[cazz]

have not config my raspberry to send mail.

[Curt Timmerman]

have not config my raspberry to send mail.

it should be sent locally to your user id.
Also cron does not read your login profile script.


Curt

[cazz]

ohh ok, well crontab is new for me so I have no idea what to do if I get error

[skidoobond]

I'm not sure, but I don't think */5 is valid time reference for cron. The first parameter is the clock minutes for the scheduled task. For example, I have a task that runs my reboot script every half hour by:
30 * * * * /home/pi/rboot.sh

[rpdom]

I'm not sure, but I don't think */5 is valid time reference for cron. The first parameter is the clock minutes for the scheduled task. For example, I have a task that runs my reboot script every half hour by:
30 * * * * /home/pi/rboot.sh

*/5 is perfectly valid. It means "run every 5 minutes"

30 means "run at 30 minutes past the hour", so not every half hour.

From "man 5 crontab":

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 every other hour (the alternative in the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''.

[cazz]

hmm where does the error log go if that is something strange with crontab?

[jojopi]

*/5 * * * * /home/pi/temp/kor.sh >/dev/null 2>&1

You realise that this is not the same as being in /home/pi/temp and running ./kor.sh? Cron will start the job with a working directory of /home/pi. So your shell wrapper may not find the python script, or it could be writing the file in the wrong place. In fact it is best to assume nothing about the working directory, and use an explicit cd if necessary.

If the job produces any output that is not redirected then cron will try to mail you that output. But that will fail unless you have installed an MTA. /var/log/syslog will log the fact that the job was attempted, but not much more.

[skidoobond]

Thanks for the clarification. I was confused by the manual on that point.

[paulknewton]

Yes - my experience with working with cron jobs, is that the problem will be one of:

- permissions (do you have exec access or write access to the correct files)? In your case, it sounds like you do
- PATHs (can cron find the various programs that are used by your script)? e.g. python, but also any shell commands
- environment (does your script rely on env. variables which are set in your profile, but not when running from cron?) This could be your problem.
- exec location. Is the script being executed from the place you think it is?

Good luck!

regards,
paul.

[Zong]

RE: with cron, get "No MTA installed, discarding output" in syslog.

I'm using Debian Wheezy 3.2.27.
I want to use cron on raspberry Pi to log data from a solar controller.

From the command line, I run the script VBtest2RP, which first sends the date and time to the logfile, in this case VBR130516, then telnets the controller and pipes the received data through a decoding script, the output of this being again redirected to the logfile:

~/VBStuff $ VBtest2RP >> VBR130516

which produces a logfile like this:
2013-05-16T08:00+01 39.0 32.6 37.3 25.5 0 0 1713 2350
2013-05-16T09:00+01 41.9 35.4 37.0 38.0 0 0 1714 2350

If I get cron to run the script, it writes the date/time to the logfile OK, but no telnet data, and I get the above message about "No MTA installed" in the syslog. I'm using full paths in all scripts.

After reading the posts about environment and so on, I compared the output of env > /tmp/myenv in cron and in the command line and changed various things in the crontab file, like PATH, adding MAILTO, and other things, but all with no effect.

The relevant bit of the crontab looks like this:
...
SHELL=/bin/sh
#MAILTO=pi
MAILTO=/var/mail/pi
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

#20130506 Raspi crontest every 3 min
#Works, but only prints date.
*/3 20-22 * * 2 /usr/local/bin/VBtest2RP >> /home/pi/VBStuff/CrontestF
...
I've used cron before, in a similar application running on a modified Sweex router and it's been working fine for years!

I'm not interested at this point in cron sending e-mails, I just want it to log the data! Anyone any ideas, please?
Thanks

[jojopi]

*/3 20-22 * * 2 /usr/local/bin/VBtest2RP >> /home/pi/VBStuff/CrontestF

Add a 2>>/home/pi/VBStuff/CrontestF.err and then check that file to see what the errors are. (Or 2>&1 to put the errors in the same file as the output.)

Once you redirect both stdout and stderr there will be nothing left over to email and cron will stop complaining about the MTA.

[Zong]

Thanks for quick reply.
Aha! Now I can see the error: "connection closed by foreign host". Which is strange: I wonder why it works from the command line and not from cron? The scripts involved, in /usr/local/bin, all have full execute permissions... and telnet itself seems to, as far as I can see, [but I don't know anything about links]:

pi@raspberrypi /etc/alternatives $ ls -l telnet
lrwxrwxrwx 1 root root 22 May 6 10:24 telnet -> /usr/bin/telnet.netkit

pi@raspberrypi /usr/bin $ ls -l telnet*
lrwxrwxrwx 1 root root 24 May 6 10:24 telnet -> /etc/alternatives/telnet
-rwxr-xr-x 1 root root 72180 Apr 15 2012 telnet.netkit

So, I can't see any "permissions" reason for this error... probably something obvious that I've missed.

[jojopi]

Unless you are piping something into telnet, it will inherit its standard input stream from the parent shell. From the command line that will be your controlling terminal, but cron attaches /dev/null as stdin.

Reading from /dev/null returns no bytes, without waiting, which is an end of file indication. This prevents any interactive processes included in cron jobs from sitting around waiting for input that is not going to come. But telnet will report the end of file to the remote host, which may close the connection immediately.

So, you might need something like "sleep 60 | telnet host …". The sleep produces no output, but there is no end of file condition until it times out and exits.

[Zong]

Hi Jojopi,

I tried your suggestion and... YIPPEE! it works! I never would have thought of that.

Thanks for a very clear explanation

[cfreyberg]

Going back to the original question:-

There seems to be a difference in the redirection capabilities of (raspian) cron and bash. For example, the (pi) crontab entry:

Code: Select all

*/10 * * * * ls -l > ./Ten.log 

creates (and recreates every 10 minutes) the expected file Ten.log containing a listing of pi's home directory. However

Code: Select all

*/10 * * * * ls -l &> ./Ten.log 

creates (and recreates every 10 minutes) an empty file Ten.log.

Why is this?

Chris F

[rpdom]

Code: Select all

*/10 * * * * ls -l &> ./Ten.log 

creates (and recreates every 10 minutes) an empty file Ten.log.

Why is this?

I think the "&>" is a bash short-hand for "2>&1 >" and as cron entries are run using /bin/sh, it won't support that.

[cfreyberg]

Thanks, rpdom.

I've been digging around and this is what I've found.

1. According to the POSIX documentation, cron starts crontab tasks in an environment that uses/includes the default ('system') shell /bin/sh. But in raspbian (debian too?) /bin/sh just references /bin/dash - type man sh and you get the dash pages. So commands put in a crontab start in dash.

2. Sure enough, according to man dash, dash does not recognise the (bash) redirection operators &> and &>>. So what did dash make of the &> in 'ls -l &> ./Ten.log'? Like bash, dash recognises a 'control' operator & that puts execution the part of the command line that preceded the & into the background. So I think dash read

Code: Select all

ls -l &> ./Ten.log

as

Code: Select all

ls -l & > ./Ten.log

and started ls -l, put that process into the background without redirection, then processed the redirection (which created the empty log file).

3. The raspbian documentation I traversed is, in places, incorrect and seemingly inconsistent. For example, man dash ( and man sh) says

dash is the standard command interpreter for the system. […]

Overview
The shell is a command that reads lines from either a file or the terminal, interprets them, and generally executes other commands. It is the program that is running when a user logs into the system (although a user can select a different shell with the chsh(1) command). […]

However, by default in raspbian (and debian?) an interactive user logs in and gets bash, not dash.

And I could not find anything in (raspbian) man cron or man crontab that specifies what shell tasks are started in. I needed to go to the POSIX documentation for that.

4. It seems that dash was created because bash was considered too big and too slow, especially at boot time. I can sort-of follow the logic that then led to dash being installed as the default or 'system' shell. But then someone reverted? the default interactive shell to bash, presumably because bash was somehow better for interactive users, without changing the man pages for dash.

Like many a new user of raspbian, I guess, I expected that by default a command line I made up would have the same effect entered interactively or run from my own 'script' (I regard my crontab entry as a 'script'). It seems such a natural thing to do is to try a command line out then put it in a script. At the very least, the little introduction that gets inserted into every new user crontab 'script' by crontab -e should include a warning that crontab tasks may/probably will not be started using the same shell that the user is currently logged-in to. That would have saved me a heap of time!

(Ideally in addition man crontab should contain more comprehensive information about the task starting environment and man sh should not be incorrect as to dash being the shell that a user logs in to.)

Chris F

[jojopi]

And I could not find anything in (raspbian) man cron or man crontab that specifies what shell tasks are started in. I needed to go to the POSIX documentation for that.

You should look at "man 5 crontab".

[rpdom]

The dash shell is similar, but not identical to bash. There are, as you have found, a few differences.

dash is a bit faster than bash, as it is smaller, has less features and depends on fewer library files, that is why it is used for cron.

[cfreyberg]

@ jojopi
Thanks. Yes, that would have done nicely.

And, as a new unix/linux/raspbian user, I've learned an essential lesson about system documentation conventions.

Thanks once again to you both for your help.

Chris F

[arntgur]

Just wrap your cron command this way:

/bin/bash -c ' <your command here...> '

There has got to be a better way to specify bash on the cron file level once and not force wraping all commands with it on every cron line. But simply adding

!#/bin/bash

didn't work for me and I have not tried:

#!/usr/bin/env bash

Other users reported that

SHELL=/bin/bash

didn't work either.

[Paeryn]

There has got to be a better way to specify bash on the cron file level once and not force wraping all commands with it on every cron line. But simply adding

Code: Select all

!#/bin/bash

didn't work for me and I have not tried:

Code: Select all

#!/usr/bin/env bash

Other users reported that

Code: Select all

SHELL=/bin/bash

didn't work either.

Putting a shebang line in the crontab won't have any effect.

Putting

Code: Select all

SHELL=/bin/bash

at the top of your crontab definitely works. In fact you can change the SHELL variable between job lines to have jobs running under different shells if you so wish.

[rpiuser2016]

crontab -e
*/15 * * * * python /home/pi/DHT22-TemperatureLogger/DHT22logger.py
-----
does not start automatically after reboot pi2b