I''ve been using puppet for a while but I just recently decided to
start using it to manage crontabs.
It works great but puppet is reporting (and being very noisy about it)
every time it does a run even when there is nothing in the actual
crontab to change.
I think this is happening because I''m setting defaults for the Cron
type, which I should be able to do. Right?
eg: Cron { environment => [ ''PATH=/bin'',
''SHELL=/bin/sh'' ] }
Before I file it as a bug, I thought I''d ask if anyone is doing
something similar or if this can be worked around by rewriting the
manifest, or if I''m doing something wrong that someone can point out.
I''m pretty sure this issue will go away if I specify the environment
for each cron entry rather than setting a default, but those aren''t
the droids I''m looking for.
An example of the "noise" I''m seeing in reports [sorry for
the rewrapping]:
Thu Jul 26 23:16:59 +0000 2007
//server8/cronstuff/Cron[foo]/environment (notice): environment
changed
''SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin''
to
''SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin''
Thu Jul 26 23:17:04 +0000 2007
//server8/cronstuff/Cron[bar]/environment (notice): environment
changed
''SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin''
to
''SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin''
And, the culprit:
class cronstuff {
# First set defaults for all cron entries
Cron { environment => [
''SHELL=/bin/sh'',
''HOME=/var/log'',
''PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin'' ]
}
cron { foo:
user => nobody, minute => "*/15", ensure => present,
command => "/foo/bin/stuff.sh"
}
cron { bar:
user => nobody, minute => "*/15", ensure => present,
command => "/foo/bin/things.sh"
}
}
cheers/thanks for replies.
On Jul 26, 2007, at 6:43 PM, ben wrote:> > I think this is happening because I''m setting defaults for the Cron > type, which I should be able to do. Right?There''s no functional difference between using defaults and setting them manually -- the defaults are entirely language constructs, and the client doesn''t know anything about them, so this can''t be the culprit. It''s easy to test this if you''re still not convinced, though.> eg: Cron { environment => [ ''PATH=/bin'', ''SHELL=/bin/sh'' ] } > > Before I file it as a bug, I thought I''d ask if anyone is doing > something similar or if this can be worked around by rewriting the > manifest, or if I''m doing something wrong that someone can point out. > > I''m pretty sure this issue will go away if I specify the environment > for each cron entry rather than setting a default, but those aren''t > the droids I''m looking for.Have you tested this?> An example of the "noise" I''m seeing in reports [sorry for the > rewrapping]: > > Thu Jul 26 23:16:59 +0000 2007 > //server8/cronstuff/Cron[foo]/environment (notice): environment > changed ''SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/ > usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/ > sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/ > log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin'' > to ''SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/ > sbin:/usr/local/bin'' > Thu Jul 26 23:17:04 +0000 2007 > //server8/cronstuff/Cron[bar]/environment (notice): environment > changed ''SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/ > usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/ > sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/ > log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/ > bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/ > local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/ > bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/ > bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin'' > to ''SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/ > sbin:/usr/local/bin''What version of Puppet is this? I fixed a bunch of cron bugs in 0.23.1. I can see what''s going on here, but I can''t promise the bug was fixed. If you''re not using the latest, can you try it and let me know if it still fails? -- It''s not the voting that''s democracy, it''s the counting. -- Tom Stoppard --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 30/07/07, Luke Kanies <luke@madstop.com> wrote:> > eg: Cron { environment => [ ''PATH=/bin'', ''SHELL=/bin/sh'' ] } > > > > I''m pretty sure this issue will go away if I specify the environment > > for each cron entry rather than setting a default, but those aren''t > > the droids I''m looking for. > > Have you tested this?I have now, and the behaviour is the same.> > Thu Jul 26 23:17:04 +0000 2007 > > //server8/cronstuff/Cron[bar]/environment (notice): environment > > changed ''SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/ > > usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/ > > sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/ > > log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin,SHELL=/ > > bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/ > > local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/ > > bin:/usr/sbin:/usr/local/bin,SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/ > > bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin'' > > to ''SHELL=/bin/sh,HOME=/var/log,PATH=/etc:/bin:/sbin:/usr/bin:/usr/ > > sbin:/usr/local/bin'' > > What version of Puppet is this? I fixed a bunch of cron bugs in > 0.23.1. I can see what''s going on here, but I can''t promise the bug > was fixed.It''s 0.23.1. It was 0.23.0 on the clients but I tried upgrading today to see if it would help. It didn''t. I saw in the trac that one of the bugs with cron that had recently been fixed was the ability to *change* crontabs with puppet. Upgrading fixed that, but may have introduced this new problem. Also, if it helps. I''m dealing with Vixie cron on Freebsd 6.x> If you''re not using the latest, can you try it and let me know if it > still fails?Yeah, it does. Also, it''s been adding extra environment setting lines to my crontabs with every run, so now I have a 70,000 line crontab one machine.. That looks something like this, PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin [etc, etc, etc...] 45 * * * * find /tmp/ -name "sess_*" ! -name "sess_hm*" -cmin +240 -exec rm -f {} \; &> /dev/null Even when I run crontab -r to delete the crontab, the next time puppet runs it adds thousands of PATH= lines again.
On Jul 30, 2007, at 3:21 PM, ben wrote:> On 30/07/07, Luke Kanies <luke@madstop.com> wrote: >> >> Have you tested this? > > I have now, and the behaviour is the same.Okay, I figured that would be the case.> It''s 0.23.1. It was 0.23.0 on the clients but I tried upgrading today > to see if it would help. It didn''t.Ok.> I saw in the trac that one of the bugs with cron that had recently > been fixed was the ability to *change* crontabs with puppet. Upgrading > fixed that, but may have introduced this new problem.I''m not really sure.> Also, if it helps. I''m dealing with Vixie cron on Freebsd 6.xDo I have to do something special to use Vixie cron on Freebsd? The only FreeBSD image I have is 5.4, is it running vixie cron? How can I tell?>> If you''re not using the latest, can you try it and let me know if it >> still fails? > > Yeah, it does. Also, it''s been adding extra environment setting lines > to my crontabs with every run, so now I have a 70,000 line crontab one > machine.. > > That looks something like this, > > PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin > PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin > PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin > PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin > [etc, etc, etc...] > 45 * * * * find /tmp/ -name "sess_*" ! -name "sess_hm*" -cmin +240 > -exec rm -f {} \; &> /dev/null > > Even when I run crontab -r to delete the crontab, the next time puppet > runs it adds thousands of PATH= lines again.In one run? Where is the header in relation to the path lines? I guess both the main cron header and the per-job header. -- Computers are not intelligent. They only think they are. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Mon, 2007-07-30 at 17:07 -0500, Luke Kanies wrote:> Do I have to do something special to use Vixie cron on Freebsd? The > only FreeBSD image I have is 5.4, is it running vixie cron? How can I > tell?Vixie cron is the default cron on FreeBSD 6.x. Not sure about 5.x, but "man -k cron" might tell you: man -k cron cron(8) - daemon to execute scheduled commands (Vixie Cron) Dane
On 30/07/07, Luke Kanies <luke@madstop.com> wrote:> Do I have to do something special to use Vixie cron on Freebsd? The > only FreeBSD image I have is 5.4, is it running vixie cron? How can I > tell?I was going by the AUTHOR section of the cron man pages on a FreeBSD 6.2 box.> In one run?Ya.> Where is the header in relation to the path lines? I guess both the > main cron header and the per-job header.It''s all where it should be. What''s happening is it''s producing usable crontabs, it just happens to be inserting the environment lines into the file thousands of times instead of 1 for all but the first entry. On each subsequent run it adds more lines. Eventually it kills puppetd. I''ll look into it more tomorrow, and see what I can do to reproduce it.
Adding the environment settings to crontabs thousands of times seems to be a bug in 0.23.1. With 0.23.0 the crontab is written correctly. However, on each additional run puppet says it''s changing the environment for each cronjob from [environment repeated a bunch of times] to [environment]. On each puppet run afterwards, the number of times the old environment is repeated increases- but the crontabs are always written correctly. 0.23.1 is doing that too but also writing out the huge crontabs.
On 01/08/07, ben <pr0ncracker@gmail.com> wrote:> Adding the environment settings to crontabs thousands of times seems > to be a bug in 0.23.1.It''s happening in 0.23.0 now too. The issue was mentioned in the comment of a trac ticket: http://reductivelabs.com/trac/puppet/ticket/705 So I broke it out into it''s own ticket: http://reductivelabs.com/trac/puppet/ticket/749