The process will wait for good data forever about lol_dht22

[technion]

Is this realistically a problem?
If you run this once per minute or whatever on a schedule, the locking mechanics will cause your new process to identify the old one is still running, and exit. The locking mechanic exists for this reason, and is less error prone (for example, a user could still set it to loop more than the amount of seconds until next execution).

[mronnlun]

The problem is that if there is some anomaly that causes bad data, e.g. a cable to the dht22 is loose, and you solve it by cutting the power from your device (e.g. Raspberry) the lock file will remain in place.

That means that every cronjob would have to start with killing possible loldht processes and removing possible lock files. Maybe this needs to be done anyway even if the loldht process would have a timeout.

[shrx]

^This happened to me more than once. Caused me some trouble before I figured out I had to manually delete the old lock file.