A quick fix for anyone running into this problem: load_schedule was crashing cron_trigger.rb#160, and I found that for triggers like "0 20 5 * * * *" it was putting in 32 for the date (even though its Mon Mar 31 04:16:21 BST 2008). Something to do with switching to day light savings I think, which concludes after 2am. I patched it by adding day = 31 if day == 32 on the line before. Not sure if there are any ramifications to this, but it seems to be running now. Zach (I''m running r303 right now. possibly this has been fixed) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080330/8221c491/attachment-0001.html
Apparently this hasn''t fixed it -the scheduler has been firing off
workers
repeatedly ("0 50 2 * * * *" firing off every few seconds etc). Will
post
any findings later.
Zach
On Sun, Mar 30, 2008 at 11:21 PM, Zachary Powell <zach at
plugthegap.co.uk>
wrote:
> A quick fix for anyone running into this problem:
>
> load_schedule was crashing cron_trigger.rb#160, and I found that for
> triggers like "0 20 5 * * * *" it was putting in 32 for the date
(even
> though its Mon Mar 31 04:16:21 BST 2008). Something to do with switching to
> day light savings I think, which concludes after 2am. I patched it by
adding
>
> day = 31 if day == 32
>
> on the line before. Not sure if there are any ramifications to this, but
> it seems to be running now.
>
> Zach
>
> (I''m running r303 right now. possibly this has been fixed)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080331/1c07f12e/attachment.html
thanks Thomas,
Mm, I think my first patch was making it fire repeatedly because the time it
created was in the past. I''ve improved it (move forwards not back), but
obviously its still a hack around the issue. not even sure if they''re
firing
at the right time (but as they''re early morning maintenance scripts 1
hour
off is no big deal):
server/cron_trigger.rb#160:
begin
s = "#{sec}, #{min}, #{hour}, #{day}, #{month}, #{year}, #{wday},
#{yday}, #{isdst}, #{zone}"
if(day == 32)
day = 1
month += 1
if(month == 13)
month = 1
year +=1
end
end
s2 = "#{sec}, #{min}, #{hour}, #{day}, #{month}, #{year}, #{wday},
#{yday}, #{isdst}, #{zone}"
puts "changed\n#{s}\n#{s2}" unless s == s2
Time.local sec, min, hour, day, month, year, wday, yday, isdst, zone
rescue => e
raise "failed\n#{s}\n\#{s2}"
end
which produced this in the log:
changed
0, 0, 0, 32, 3, 2008, 1, 91, true, BST
0, 0, 0, 1, 4, 2008, 1, 91, true, BST
changed
30, 0, 0, 32, 3, 2008, 1, 91, true, BST
30, 0, 0, 1, 4, 2008, 1, 91, true, BST
changed
0, 10, 5, 32, 3, 2008, 1, 91, true, BST
0, 10, 5, 1, 4, 2008, 1, 91, true, BST
changed
0, 20, 5, 32, 3, 2008, 1, 91, true, BST
0, 20, 5, 1, 4, 2008, 1, 91, true, BST
changed
30, 20, 0, 32, 3, 2008, 1, 91, true, BST
30, 20, 0, 1, 4, 2008, 1, 91, true, BST
changed
0, 0, 0, 32, 3, 2008, 1, 91, true, BST
0, 0, 0, 1, 4, 2008, 1, 91, true, BST
changed
0, 50, 2, 32, 3, 2008, 1, 91, true, BST
0, 50, 2, 1, 4, 2008, 1, 91, true, BST
unfortunately i''ve got too much going on to look into a proper fix, but
i''ll
post one in a few weeks once the busy period has blown over (hopefully this
will hold out, seems logical..)
On Mon, Mar 31, 2008 at 5:56 AM, Thomas R. Koll <tomk32 at gmx.de> wrote:
>
> Am 31.03.2008 um 05:21 schrieb Zachary Powell:
> > A quick fix for anyone running into this problem:
> >
> > load_schedule was crashing cron_trigger.rb#160, and I found that
> > for triggers like "0 20 5 * * * *" it was putting in 32 for
the
> > date (even though its Mon Mar 31 04:16:21 BST 2008). Something to
> > do with switching to day light savings I think, which concludes
> > after 2am. I patched it by adding
> >
> > day = 31 if day == 32
>
> I guess this version would be better for now (until some madman
> changes the whole world, uhh don''t read my sig)
>
> day = 31 if day > 31
>
> ciao, tom
>
> --
> Thomas R. "TomK32" Koll || http://tomk32.de ||
http://ananasblau.com
> (NEW)
> just a geek trying to change the world
> Skype: TomK32 || Mail: tomk32 at gmx.de
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080331/51a19874/attachment.html
On Mon, Mar 31, 2008 at 6:26 PM, Zachary Powell <zach at plugthegap.co.uk> wrote:> thanks Thomas, > > Mm, I think my first patch was making it fire repeatedly because the time it > created was in the past. I''ve improved it (move forwards not back), but > obviously its still a hack around the issue. not even sure if they''re firing > at the right time (but as they''re early morning maintenance scripts 1 hour > off is no big deal): > > server/cron_trigger.rb#160: > > > begin > s = "#{sec}, #{min}, #{hour}, #{day}, #{month}, #{year}, #{wday}, > #{yday}, #{isdst}, #{zone}" > if(day == 32) > day = 1 > month += 1 > if(month == 13) > month = 1 > year +=1 > end > end > s2 = "#{sec}, #{min}, #{hour}, #{day}, #{month}, #{year}, #{wday}, > #{yday}, #{isdst}, #{zone}" > puts "changed\n#{s}\n#{s2}" unless s == s2 > Time.local sec, min, hour, day, month, year, wday, yday, isdst, zone > rescue => e > raise "failed\n#{s}\n\#{s2}" > end > > which produced this in the log: > > > changed > 0, 0, 0, 32, 3, 2008, 1, 91, true, BST > 0, 0, 0, 1, 4, 2008, 1, 91, true, BST > changed > 30, 0, 0, 32, 3, 2008, 1, 91, true, BST > 30, 0, 0, 1, 4, 2008, 1, 91, true, BST > changed > 0, 10, 5, 32, 3, 2008, 1, 91, true, BST > 0, 10, 5, 1, 4, 2008, 1, 91, true, BST > changed > 0, 20, 5, 32, 3, 2008, 1, 91, true, BST > 0, 20, 5, 1, 4, 2008, 1, 91, true, BST > changed > 30, 20, 0, 32, 3, 2008, 1, 91, true, BST > 30, 20, 0, 1, 4, 2008, 1, 91, true, BST > changed > 0, 0, 0, 32, 3, 2008, 1, 91, true, BST > 0, 0, 0, 1, 4, 2008, 1, 91, true, BST > changed > 0, 50, 2, 32, 3, 2008, 1, 91, true, BST > 0, 50, 2, 1, 4, 2008, 1, 91, true, BST > > > unfortunately i''ve got too much going on to look into a proper fix, but i''ll > post one in a few weeks once the busy period has blown over (hopefully this > will hold out, seems logical..) >No problems. I will try to look into this, during weekend and see what can be done about this.