Issues with Cron

[trivium91]

Hi Guys I have Raspbian Jessie, I'm trying to run a command every 1 minute.

*/1 * * * * /usr/local/bin/rsump.py


cron appears to be running but it will not execute the command. If I put the file path in manually it will work. I''ve reflashed the card several times and set this up several times with the same result.

[knute]

I'm not sure that */1 is different from * but here nor there.

The python interpreter is not in pi's crontab path so it won't run. Try:

* * * * * python /usr/local/bin/rsump.py

[n67]

I'm not sure that */1 is different from * but here nor there.

Correct. It is irrelevant, but see below for further discussion of the idea of running something every minute.

The python interpreter is not in pi's crontab path so it won't run.

False. On any normal Raspbian system (and probably any/all others), both python and python3 are in /usr/bin and, despite all and sundry claims to the contrary that you may see either on these forums or online, /usr/bin is in the default PATH.

Try:

Code: Select all

* * * * * python /usr/local/bin/rsump.py

This can't possibly be an improvement, since either python is in the default PATH (as it most certainly is) or it (i.e., the above command line) won't find it, because no full path to python was given.

In other words, ITYM:

Code: Select all

* * * * * /usr/bin/python /usr/local/bin/rsump.py

but, as noted above, this can't possibly improve things, since /usr/bin is already in the PATH.

But for all that, running things every minute via cron is wrong for about a dozen reasons.

It has to be better to put the delay into your own code, either via Python itself or via a shell script. Since I don't know Python, I'll leave that avenue for others to explore, but I would certainly do it like this:

Code: Select all

#!/bin/bash
while :;do
    /usr/local/bin/rsump.py
    sleep 60
done

And then run that script instead. Instructions on how to get that script running automatically are beyond the scope of this lesson, but future courses may cover it (if needed).

P.S. If your "sump.py" program might error out (*) - and you would want to stop running it if it does - then you might want to change the above to:

Code: Select all

#!/bin/bash
while /usr/local/bin/rsump.py;do
    sleep 60
done

(*) I.e., return a non-zero return code if something went wrong.

[stewart_elmwood]

But for all that, running things every minute via cron is wrong for about a dozen reasons.

Your example doesn't run the script every minute: it runs the script, then waits a minute. If rsump.py takes any amount of time to run, then it'll run far less frequently than once a minute.

[n67]

But for all that, running things every minute via cron is wrong for about a dozen reasons.

Your example doesn't run the script every minute: it runs the script, then waits a minute. If rsump.py takes any amount of time to run, then it'll run far less frequently than once a minute.

Obviously. And water is wet.

But that's the gist of it. One of the dozen or so reasons why running things like this via cron is wrong is that if the program hangs, you very quickly end up with a zillion copies running. Even if it doesn't hang, it could take more than a minute to run and then you'd end up with more than one running simultaneously - which is usually a Bad Thing.

If you really need it to run exactly on the minute, refinements to the script (possibly to be covered in future lesson plans) will take care of that.

For the time being, I pretty much assumed that the program takes almost zero time to run (as is usually the case with things like this). But only the OP can tell us how long it actually takes.

[scruss]

Obviously. And water is wet.

That's quite a lot to assume. It's -10°C here right now. Water is very dry, and can be stacked neatly.

… One of the dozen or so reasons why running things like this via cron is wrong is that if the program hangs, you very quickly end up with a zillion copies running.

Not if you use locks properly. There's nothing wrong with using cron for this, if you're careful.

Even if it doesn't hang, it could take more than a minute to run and then you'd end up with more than one running simultaneously - which is usually a Bad Thing.

Yes, like the problem I had on a SCO SVR3.2 system back in '93 when a new power station monitoring system software release was shipped to us. The developers had used a 486, but had forgotten that remote sites were on 386s. Their stats process, triggered every 10 minutes by cron, ran in 5 minutes on the dev machine but 11 minutes on the remote machine. Hilarity very quickly failed to ensue.

[n67]

Not if you use locks properly. There's nothing wrong with using cron for this, if you're careful.

Been there, done that.

It is surprisingly tricky, though, to get it right. There's a lot that can go wrong, and you generally won't get it right the first time.

I'm not saying that it is hard - and smart guys like you and me can get it right. But it is a trap for the unwary.

I generally much prefer using a script - where you can control what's happening and monitor it much more easily than with cron. Just witness all the "Cron Problem" posts we see on the forum...

[knute]

The python interpreter is not in pi's crontab path so it won't run.

False. On any normal Raspbian system (and probably any/all others), both python and python3 are in /usr/bin and, despite all and sundry claims to the contrary that you may see either on these forums or online, /usr/bin is in the default PATH.

This can't possibly be an improvement, since either python is in the default PATH (as it most certainly is) or it (i.e., the above command line) won't find it, because no full path to python was given.

In other words, ITYM:

Code: Select all

* * * * * /usr/bin/python /usr/local/bin/rsump.py

but, as noted above, this can't possibly improve things, since /usr/bin is already in the PATH.
[/quote]

You're right, it was my screwed up python code that didn't work.

The path for user cron is /usr/bin:/bin.

And it works fine if my python code is correct so I don't know what the OP's problem was.