1

I followed this tutorial to log my CPU temperature into a .csv-file and try to run the .py script it at bootup with cron.

The script:

from gpiozero import CPUTemperature
from time import sleep, strftime, time
cpu = CPUTemperature()
with open("/home/user/Desktop/cpu_log.csv", "a") as log:
    while True:
        temp = cpu.temperature
        log.write("{0},{1}\n".format(strftime("%Y-%m-%d %H:%M:%S"),str(temp)))
        sleep(300)

I did a chmod 757 to the python script. Then added it to crontab -e: @reboot python3 /home/user/Desktop/log.py

If I execute python3 log.py from shell when the machine is running, the .csv file is being created and written to perfectly. However when I reboot my machine, I see the script running with ps -aux | grep log.py. And I see the .csv file being created once. However not a single line is written to the file and after I delete it, it is not recreated. There is just an empty csv file on the desktop.

  • 1
    Are you running this script on a Pi? Does the script include all those > at the start? – joan Jun 9 '18 at 7:05
3

You never flush the buffer, thus, the info is not being dumped to the file. This is done when the file is closed (you never do it), assigning a buffer size (see this stackoverflow answer and comments or flushing the buffer. To achieve the latter (and the easier IMHO), add before the sleep line:

log.flush()

It should look like:

    temp = cpu.temperature

    log.write("{0},{1}\n".format(strftime("%Y-%m-%d %H:%M:%S"),str(temp)))
    log.flush()

    sleep(300)
  • Good catch XiR_! @WaveRipper: I'm glad this fixed the problem. I am confused on one point though: you said in your OP that executing log.py from the shell ran and wrote to the file. I wonder why it writes run from the shell, but not from cron? Anyone?? – Seamus Jun 10 '18 at 14:25
  • Because when it is run from the shell, somewhen he/she sends the keyboard interruption and the process dies dumping the buffers. On th e other side, cron process runs forever (while True) and buffers are never dumped. – XiR_ Jun 10 '18 at 21:18
2

You failed to tell the cron user where python3 is located. cron's path is different than yours.

@reboot /usr/bin/python3 /home/user/Desktop/log.py

EDIT: As I have learned here recently, there are some "vagaries" associated with cron's concept of the @reboot event. To quote my mentor:

"read man crontab. It says: "Please note that startup, as far as @reboot is concerned, is the time when the cron(8) daemon startup. In particular, it may be before some system daemons, or other facilities, were startup. This is due to the boot order sequence of the machine." So you may run into problems if your program needs specific services."

If your script doesn't seem to run properly under @reboot, and that is due to the cause cited above, you can try to remedy that by delaying when cron starts your script. The other thing you should consider is redirecting the stderr output from cron to a file. All that said, your crontab entry will now look like this (make sure you get the entire line):

@reboot (sleep 30; /usr/bin/python3 /home/user/Desktop/log.py > /home/pi/cronjoblog 2>&1)

If you still have issues, check the contents of /home/pi/cronjoblog for clues.

  • 1
    There's no way that path (/usr/lib/python3) is correct, but you should be able to find it with which python3. It will probably return bin in place of the lib ;) – goldilocks Jun 9 '18 at 2:38
  • Thanks for your hints! With which python3 I was able to locate python3 in /usr/bin/. Unfortunately this did not solve the problem. Note that the script seems to be running, since the output text file is being created at every reboot (if it did not exist before). However the file is empty. – WaveRipper Jun 9 '18 at 8:50
  • @goldilocks oh crap! I copied the wrong line from sudo find / -name python3... yes, it is /usr/bin/python3. My apologies - got in too big a hurry. – Seamus Jun 9 '18 at 22:29
  • 1
    Either way it is always a good thing to provide full paths to cron. +1 – Ghanima Jun 9 '18 at 23:13
  • 1
    find / ... and go have a coffee, lol. Executables are always somewhere in one of the $PATH directories (look at echo $PATH), or else you must prefix them with a path (including ./); which is a shortcut for finding the former (see man which, and note there are a few commands that are shell built-ins that either don't have an executable path, or have a path to an executable version that isn't actually used by the shell). – goldilocks Jun 10 '18 at 10:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.