In Unix/Linux systems, lots of OS background tasks are run as cron jobs. To see what won't run if you stop the cron daemon, type these commands:
ls -la /etc/cron.hourly
ls -la /etc/cron.daily
ls -la /etc/cron.weekly
If you really know what you are doing, and you are quite sure you can deal with the consequences, only then shut down cron.
Here are my ...
Since you don't have Internet NTP, the file timestamps are meaningless, being reset to the Pi's "/etc/fake-hwclock.data" time whenever the system is booted.
If the daily data file(s) have a standard name ( e.g. /PATH/sensor1.data or common tag ( e.g. the ".data" ) you can use savelog ( or logrotate ) to save only the most recent ( e.g. &...
On a system where the time resets on boot, you can't know what time it is when the system starts, and similarly can't know how long it was when the system was down. But you can count reboots, and you probably have a clock that works while the system is up.
Have a global counter ("run id"), stored in a file or database, or whatever, that you ...
Raspbian includes fake-hwclock, which saves the clock to the SD card on shutdown and restores it on boot. However, if you're just cutting the power to restart it, this is fairly useless; it will never shut down, so it'll keep restoring the last-saved time which is the same as always.
Deanna Earley's solution is to add a line to /etc/crontab:
* * * * * root ...
You've run into a well-known limitation with cron. The question has been asked and answered here many times. This recent example highlights the two (at least two) choices you have:
use cron (older, simpler)
use systemd (newer, more complex)
The answer to your question in the context of cron usage is this:
If your script runs from the command line, but ...
Cron is actually very useful. Say you wanted to run a program once a day, then cron is your friend. You can schedule to run a program at any time during the day. I would definitely leave it on your pi. ;)
I think you are missing a shebang in the beginning of your python script.
Please write #!/usr/bin/env python for python2 or #!/usr/bin/env python3 for python3 as a first line of your .py file. Alternatively you can write your cronjob command as python /path/to/your/script.py (or python3) to specify directly what to use to run your script.
If you put all the ...
I tried sunwait, mentioned above, but found it to be a bit clunky. I rewrote a similar program, myself, called heliocron, with the advantages being that it is actively maintained, has clear documentation and even has prebuilt binaries that run on Raspberry Pis off the bat.
A basic command might look something like:
0 2 * * * heliocron --latitude 51.4769N --...
Cron is a lightweight process that doesn't use a lot of resources by itself. Plus many other things assume cron is there and working. Leave it there.
Consider installing atop for diagnostics. When the atop service is running, it periodically logs the machine's state to a file for later debugging.
I think atop defaults to every 10 minutes, but you could ...
In the context of saving power:
the RPi cannot turn itself OFF - at least not completely
the RPi cannot turn itself ON - this requires external intervention
viewed as a ROI question, consider the cost of running RPi 24x7x365 is less than £5 per year
Using cron - and only cron, here's what you can do to save power:
Scheduling a shutdown will help ensure ...
If it were me, I would get a cheap RPi zero W or just zero, or even the new rPi Pico and wire a micro USB to a PCB or breadboard with an NPN 2n2222 transistor and have it give power from the time a to time b and off otherwise. Then you have a handy little IOT switch and since you are not using mains power you can use just a transistor instead of a relay. But ...
Your question is currently unclear on some points & I've requested clarification in the comments. Until then, this may help:
cron doesn't have the same PATH that you have in the interactive shell (bash), and the system cannot find the executable file(s) you've specified in your crontab. There are a couple of ways to solve this, but perhaps the cleanest ...
arecord needs an environment variable called XDG_RUNTIME_DIR to locate the resources it needs. By default our cron jobs run in a different environment than (for example) the one in our interactive shell, and the cron environment won't (by default) include the variable XDG_RUNTIME_DIR.
The solution then is to add this environment variable in ...
Please take note that using /etc/rc.local has limitations due to Compatibility with SysV. We have seen many problems here on this site using it. Following the recommendation of the developers from systemd you should avoid using it.
You should use a systemd Unit file to start your program at bootup. You will find many answers here on this site. Please have a ...
Your /tmp permissions are in order - that's not the problem.
First guess is that your filesystem is broken. The solution is to re-flash your SD card (You do have a backup, right?).
You can also check to make sure you've not somehow inadvertently mounted your filesystem as ro:
$ mount -l -t ext4
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
The mode of /tmp is supposed to be 1777.
sudo chmod 1777 /tmp
The 777 part means anyone can read, write or search the directory.
The 1 part means only the owner of each file in the directory is allowed to delete it.
What command do you set in your crontab file? Is the script intended to run once and done or constantly post power readings?
As you mention, crons can fail because of path issues. Not only for the script but also for python if that is how you are running the script. For example:
@reboot /usr/bin/python3 /home/pi/example.py
You may wish to save the output of ...
It's been a while since I've used raspistill, but this may work as a cron job:
Create your bash script at /home/pi/camera.sh as follows:
/usr/bin/raspistill -o /home/pi/camera/$DATE.jpg
Be sure to mark it as executable :
chmod a+x /home/pi/camera.sh
Add the following line to your crontab (crontab -e):
* * ...
Since you are using stdio, a fifo might be a solution for your input. For example, open two terminals and do:
terminal 1: |terminal 2:
$ mkfifo fifo |
$ tail -f fifo | sed 's/a/A/' |$ echo hoppa > fifo
So, you could create a fifo in your ...
I found the problem.
Actually I was referring to some folders (the one where the files to upload are) with relative paths. It works when I run the script directly with python command, but not with Cron. So I updated all the paths with absolute values, and now it works :)
If a process started by crontab writes to stdout or stderr crontab sends an e-mail with that text to the local users (process owner) mail address provided that an MTA is installed and configured for local delivery.
If you had correctly redirected stderr to a file or /dev/null it should not send a mail, as it gets no output on the output channels.
You can ...
Try running that runipy command using the fully qualified name, e.g. /usr/local/bin/runipy. /etc/rc.local may not have the same $PATH as your login shell. If this command has to do with Python, try setting a sane Python environment as well ($PYTHONPATH, $PYTHONHOME, etc.)
If that doesn't help, you'll have to diagnose what "cannot seem to execute this ...
Yes. At least for now you need to specify either python or python3.
At some point, python a.k.a Python ver 2.7.16 may be deprecated, and removed from the Raspbian distribution. But when this will happen has been the subject of speculation for some time.
For now, python is version 2, and may be determined as follows:
$ python -V
This, as ...
You can figure this out for yourself - you don't need our help. (And you've not given us enough to answer your question anyway!)
You seem to be asking if it is more efficient to use polling, or interrupts. The answer is almost inevitably interrupts are more efficient. Of course you need to use an API that will pass these interrupts to your program.