Hi

Sorry my mistake.

When I am talking about crontab then I am talking about the crontab file that sets up the environment.
But you are right; It is still the CRON command and logentry; The crontab log entries only occures when you execute the crontab commant
e.g. 'crontab -l' or 'crontab -e'

What I mean is if you execute the command from the crontab file in a statndard shell than there are a lot of environment settings already working
that came from /etc/profile, /etc/bash.bashrc, .profile, .bashrc or any other envirnment files that will be called on login or console opening.

cron on the other hand has by default NO environments setup so anything that is needed by a command has to be setup by the command itself.
(or in the crontab file but that's another story)

This is most of the time the reason why a command that works in a standard shell will fail in a cron call from the crontab file.

This error looks very stange and maybe one of your installed python package is corrupted.

the line
'from time import sleep'
is a core python function to import an external package (in this case the time utils lib)

First of all you should test if the command from the crontab is working on a standard shell. The cron environment is sometimes very special.

If this is also not working  you could try the following:
start python2 on a shell and execute 'from time import sleep'
If this fails then the problem is in the python installation.
But it is working then it means that the backintime package has a problem.

Hi Lorenzo

Thanks for the hint. I have cloned the repo and have taken a (deep) look into it.
I will change some things because it is perfect for cloud and container environments where the vm is often destroyed and recreated but is IMHO not perfect for real servers/desktop. E.g. every initscript is (re)reating the symlink from /etc/init.d/* to /bin/sv what is something that should be done by a debian package or a separate install script.

So it is still best practice to check for all necessary depencies.

Yep, I totally agree with you. If stage 2 is working perfectly it may be time to step forward to change stage 1 and stage 3.
And stage 2 can be implemented as a separate independed debian package while stage 1 and stage 3 changes affects the runit debian package.

Even systemd has not a perfect solution for this problem; it still needs HI instead of KI.

Ahh, fantastic because this means there is a daemon independed way to administrate logfiles for different services to different locations. This is very useful on low memory mashine where I can pick only those log that I really need.

Thanks again for your explanations and your excellent work on the debian runit-script package.