Bill Carney's picture
Bill Carney - Sat, 2016/05/21 - 02:17

I recently restored a backup to a new instance.  Most things are running fine, except the cron task that looks like:

/etc/cron.daily/apt
/etc/cron.daily/etckeeper
/etc/cron.daily/mysqloptimize
/etc/cron.daily/man-db
/etc/cron.daily/logrotate
/etc/cron.daily/tklbam-backup
/etc/cron.daily/apache2
/etc/cron.daily/passwd
/etc/cron.daily/dpkg
/etc/cron.daily/bsdmainutils
/etc/cron.daily/ntp

Isn't running. It's set to run as root. When I run it manually from Webmin this message appears:

Output from command libuuid test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) ..
/bin/sh: 1: libuuid: not found

 I checked /var/log/syslog, and it says:

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)

All three referenced files are owned by libuuid.

When I log into Shell-in-a-Box as root and run the commands manually, they work.

Any idea what is wrong, and how to correct it?  Since it runs tklbam-backup, I'm concerened...

 

Forum: 
Support
Tags: 
restore
cron
tkl
Bill Carney's picture

Bill Carney - Sat, 2016/05/21 - 02:30

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.

Bill Carney's picture

Bill Carney - Sat, 2016/05/21 - 03:22

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?

 

Jeremy Davis's picture

Jeremy Davis - Sun, 2016/05/22 - 14:01
TBH I have no idea. Cron is not something that I've had a ton to do with.

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...

Bill Carney's picture

Bill Carney - Mon, 2016/05/23 - 07:09

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
Jeremy Davis's picture

Jeremy Davis - Mon, 2016/05/23 - 07:11
That is a weird error to get from changing permissions.

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.

Bill Carney's picture

Bill Carney - Mon, 2016/05/23 - 17:02

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

Bill Carney's picture

Bill Carney - Mon, 2016/05/23 - 17:59

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.  

Jeremy Davis's picture

Jeremy Davis - Tue, 2016/05/24 - 03:56
So the permission issue is solved then? Assuming so, it's still weird that it occurred in the first place. TKLBAM should handle the permissions of cron jobs. I recall years ago there were problems with some file permissions being set to root (when they shouldn't be) but Liraz fixed that. This seems like a new issue. But it also seems like potentially quite a critical one! If cron jobs aren't running in restored servers then that's bad!
Bill Carney's picture

Bill Carney - Tue, 2016/05/24 - 16:47

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. :(

 

 

Jeremy Davis's picture

Jeremy Davis - Wed, 2016/05/25 - 03:29
It seems totally weird. Everything I have read about cron suggests that so long as the files are owned by cron they should "just work"!

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...

Bill Carney's picture

Bill Carney - Wed, 2016/05/25 - 19:03

-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

Bill Carney's picture

Bill Carney - Thu, 2016/05/26 - 13:10

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.

Bill Carney's picture

Bill Carney - Fri, 2016/05/27 - 16:46

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.

 

Jeremy Davis's picture

Jeremy Davis - Tue, 2016/05/31 - 03:34
That is really weird! I still don't understand... But anyway, glad that it's working now.

Add new comment