TKL cron tasks not running after restore to a new instance

About a minute after I posted this I retsarted my original server, and copied the contents from that instance's /etc/crontab to the new instance.  I retsarted the cron service, and now it looks like it's functioning again when I run the task manually from Webmin.  We'll see tomorrow if it updates my tklbackup automatically.

Still getting these error messages in /var/log/syslog

May 21 00:17:01 lamp cron[6319]: (*system*) WRONG FILE OWNER (/etc/crontab)
May 21 00:17:01 lamp cron[6319]: (*system*cron-apt) WRONG FILE OWNER (/etc/cron.d/cron-apt)
May 21 00:17:01 lamp cron[6319]: (*system*php5) WRONG FILE OWNER (/etc/cron.d/php5)

Any idea what's up?

But my guess is that the files in question are owned by the wrong user. AFAIK they should be owned by root (backed by the fact you said that they run when launched by root). Assuming that you can still access the old server, I suggest that you check the file permissions and owner on the old server and compare them to the new one. The easiest way is to use "ls -l /etc/cron.d" etc...

I hope I haven't lead you too far astray...

TBH I'm not really sure what is going on. I'll need to have a play with TKLBAM and see if I can recreate the issue and try to fix it.

I changed all permissions to root, and now I'm getting this error - and backups are still not working:

Traceback (most recent call last):
File "/usr/bin/tklbam-backup", line 510, in <module>
main()
File "/usr/bin/tklbam-backup", line 218, in main
conf = Conf()
File "/usr/lib/tklbam/conf.py", line 153, in __init__
self.overrides = Limits.fromfile(self.paths.overrides)
File "/usr/lib/tklbam/conf.py", line 46, in fromfile
raise Error(`limit` + " is not a legal limit")
conf.Error: 'echo' is not a legal limit

FWIW it ran a long time before that error popped up.  Now, when I run tklbam-backup from the shell, the error appears immediately.

Ok, the error message above isn't related to my cron issue; I had forgotten that I changed tklbam's advanced config to make a full backup every 14 days.  After I removed that, the error message doesn't appear and the backup runs when I execute it manually.  

-rw-r--r-- 1 root root 721 May 24 14:12 /etc/crontab 

-rw-r--r-- 1 root root 173 May 20 23:02 /etc/cron.d/cron-apt                                                                                          
                                                                                                               
-rw-r--r-- 1 root root 464 May 19 14:35 /etc/cron.d/php5

However I did note a couple of caveats, that the files must not be writeable by anyone other than root. And if the files are symlinks (which they shouldn't be in the case) the files that they point to need to be also owned by root (and not writeable by anyone else).

So just to be 100% sure that you are meeting all of those criteria please provide the out put of the following:

ls -l /etc/crontab
ls -l /etc/cron.d/cron-apt
ls -l /etc/cron.d/php5

Also for what it's worth, TurnKey is Debian under the hood (v14.x = Debian Jessie) so there should be tons of online reading...

The cron issue isn't solved - just the error message I posted above is.  I changed the permissions to root:root and this error message went away:

May 20 23:09:01 lamp cron[454]: (*system*) WRONG FILE OWNER (/etc/crontab)
May 20 23:09:01 lamp cron[454]: (*system*cron-apt) WRONG FILE OWNER (/etc/cron.d/cron-apt)
May 20 23:09:01 lamp cron[454]: (*system*php5) WRONG FILE OWNER (/etc/cron.d/php5)

However, all the daily maintenance (including tklbam-backup) isn't running via cron. I have to run it manually to get it to back up. :(

This is bizarre.  I didn't do anything on the instance yesterday with the exception of running the three ls commands above, changing the port Adminer listens on to 8000, and then issuing an Apache service restart.  This morning I awoke to an email from the Cron Daemon with the results of /etc/cron.daily/tklbam-backup.

I'll sit on this and see if it runs again tomorrow.

The cron job ran again last night.  I don't know what the issue was, but it appears to be solved.  It's very strange.