[wp-trac] [WordPress Trac] #57271: Cron unschedule / reschedule event errors

WordPress Trac noreply at wordpress.org
Tue Mar 5 20:25:32 UTC 2024


#57271: Cron unschedule / reschedule event errors
----------------------------------------+------------------------------
 Reporter:  domainsupport               |       Owner:  audrasjb
     Type:  defect (bug)                |      Status:  assigned
 Priority:  normal                      |   Milestone:  Awaiting Review
Component:  Cron API                    |     Version:  6.0
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+------------------------------

Comment (by j3gaming):

 Replying to [comment:58 domainsupport]:
 > Replying to [comment:57 j3gaming]:
 > > I posted my logging code, and the output of the logs on the other
 ticket:
 > > https://core.trac.wordpress.org/ticket/57924#comment:15
 > >
 > > I was able to get an output of 2 distinct, but very close microtimes.
 > >
 > > Not using wp cron, it is disabled in wp-config. On linux, I'm using
 the OS cron:
 > > https://core.trac.wordpress.org/ticket/57924#comment:17
 >
 > The difference between your microtimes is 0.000369 of a second which may
 well be fast enough to not have time to save the locking transient before
 trying to read it to see if there is a lock!
 >
 > The proposed fix to your unique issue could be `usleep(rand(500000,
 2000000);` (sleep for a random amount of time between half a second and
 two seconds) rather than `sleep(2);` which would just prolong the same
 issue for two seconds.
 >
 > But I feel like the real fix for you is to find out why your system is
 firing cron twice at exactly the same time. Because if you've disabled wp
 cron then it surely ''must'' be your system that's causing the duplicate
 cron events? And maybe it only causes the error for you when you're
 running the backup because when that's happening perhaps it loads the
 database sufficiently to not save the transient in time to be read by the
 subsequent cron event ... ?


 Maybe, that code for sleep would probably work. My goal was to not edit
 the core files. I simply changed the way my cron events are processed. All
 is funning fine here, even if 2 are fired at once.

 I have our major PHP version change, and linux update upcoming here, so
 maybe it's been fixed and I'm just behind on updates.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57271#comment:59>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list