I have a bunch of EL6 (Scientific Linux, to be precise) containers up and running from a bunch of EL6 HNs. Today I discovered that my log files on those containers was never rotated. Literally: _never_. I've started to dig why the bloody hell. I thought of everything. First of all I thought about broken logrotate, but the verbose runs from command line showed me that it works just fine. After that I thought that there is something dirty with cron. It appears that Red Hat made a switch from vixie-cron to cronie on their EL6 release. I checked the /var/log/cron log and the contents of the /etc/cron.d directory and learned that cronie only runs hourly jobs the regular way. No daily stuff there. That surprised me as shit. I started to dig further. From that hourly job (/etc/cron.d/0hourly) it runs the contents /etc/cron.hourly using run-parts as it should. And there is only one script inside cron.hourly -- 0anacron. Anacron does the job now. It has its advantages, but it's not the topic. There is two packages bundled inside EL6: cronie-anacron and cronie-noanacron. First one does stuff regularly as we all are keen to and the second one is the default which has this asynchronous behavior. Well, let's stick to the defaults. After learning all that stuff I took a look at one of my HN and I saw there that anacron was doing just fine there. It was running daily as it should, there were traces of anacron in /var/log/cron log. On the container, /var/log/cron was clean of anacron traces. It means that it never worked there. That's some bloody mess, eh? So, if the HN is fine and problem only appears inside the containers it was obvious that there is something broken inside the template. I use custom Scientific Linux templates based off the default one from the website. It appears that on normal SL6 install the /etc/cron.hourly/0anacron is 755, while inside my template it was 644. That's the problem. All hourly runs were dry runs, hence no daily runs, no logrotates, et cetera. I've downloaded the original scientific-6-x86_64 template from the website and checked it. It has that problem. Out of curiosity I've checked the centos-6-x86_64 template -- it has that problem too. So while I'm writing a quick puppet hack to change the permission bits on my affected hosts, why don't you fix your templates, eh? It's a disaster, really. -- SY, Ilya A. Otyutskiy aka Sharp
On Sat, Jan 7, 2012 at 10:06 PM, Ilya A. Otyutskiy <sharp@thesharp.ru> wrote: > So while I'm writing a quick puppet hack to change the permission bits > on my affected hosts, why don't you fix your templates, eh? It's a > disaster, really. And, of course, the bugzilla entry: http://bugzilla.openvz.org/show_bug.cgi?id=2132 -- SY, Ilya A. Otyutskiy aka Sharp
Greetings, ----- Original Message ----- > It appears that on normal SL6 install the /etc/cron.hourly/0anacron > is 755, while inside my template it was 644. > That's the problem. All hourly runs were dry runs, hence no daily > runs, no logrotates, et cetera. > > I've downloaded the original scientific-6-x86_64 template from the > website and checked it. It has that problem. Out of curiosity I've > checked the centos-6-x86_64 template -- it has that problem too. I can confirm this to be the case although I wouldn't use the word "disaster" nor "shit"... but to each his own. I have a container made from an earlier official OS template release and the file in question is 755 where the current OS template shows: [root@sl6test32 /]# ls -lha /etc/cron.hourly/0anacron -rw-r--r-- 1 root root 424 Mar 26 2011 /etc/cron.hourly/0anacron [root@sl6test32 /]# rpm -qf /etc/cron.hourly/0anacron cronie-anacron-1.4.4-7.el6.i686 [root@sl6test32 /]# rpm -V cronie-anacron-1.4.4-7.el6.i686 .M....... /etc/cron.hourly/0anacron Luckily it is an easy problem to find and fix. Thanks for reporting the bug. I await an updated OS Template. To the best of my knowledge, the issue isn't present in the my contributed SL OS Templates. TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work]
On Sat, Jan 7, 2012 at 11:50 PM, Scott Dowdle <dowdle@montanalinux.org> wrote: > I can confirm this to be the case although I wouldn't use the word "disaster" nor "shit"... but to each his own. > So it's pretty normal for you when all of your cron jobs, which you've put inside cron.daily, just don't work, right? To me -- that seems like a disaster. // Just in case you are wondering what took me so long to figure out that there is such an issue: those cron jobs I'm talking about only produce some mail output when something's wrong. No mail -- all good. And if there was a problem, I wouldn't know about it because there were no checks. -- SY, Ilya A. Otyutskiy aka Sharp
Greetings, ----- Original Message ----- > So it's pretty normal for you when all of your cron jobs, which you've > put inside cron.daily, just don't work, right? To me -- that seems > like a disaster. It was a "bug" manifest in bad file permissions. Every bug is potentially a disaster to someone who thinks that the particular thing affected is important. To people it isn't as important to, not so much. If every bug reporter declared every bug they found important to them a disaster, I think the meaning of the word disaster would be diminished... but in the end, it is just a semantic argument that isn't very productive, eh? :) TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work]