[wp-trac] [WordPress Trac] #57924: Cron Goes Missing. _set_cron_array called with incorrect number of crons

[WordPress Trac]

#57924: Cron Goes Missing. _set_cron_array called with incorrect number of crons
--------------------------+------------------------------
 Reporter:  j3gaming      |       Owner:  j3gaming
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Cron API      |     Version:  6.1.1
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by domainsupport):

 @j3gaming Are your database tables MyISAM or InnoDB? I'm going to go out
 on a limb and guess you are running MyISAM. MyISAM uses table-level
 locking, which means that if one query is modifying a table, another query
 cannot modify the same table until the first query has completed. This can
 result in locking issues and conflicts, especially when many concurrent
 queries are accessing the same table.

 InnoDB is the default and most commonly used table engine in MySQL, and it
 provides good support for locking and concurrency, which can prevent
 conflicts and enable multiple queries to run simultaneously. InnoDB uses
 row-level locking and supports multiple concurrent transactions, which can
 help to prevent locking issues during INSERT/UPDATE queries.

 Apologies if you are already running InnoDB however.

 My earlier point, and one which I'm not 100% sure you are getting, is that
 if the database is locked up (whilst your backup is running, for example)
 it would appear that your site isn't able to run UPDATE/INSERT queries.

 In this instance, the cron option cannot be saved which means that your
 cron events cannot be rescheduled and will appear that they have been
 deleted. They haven't, they've run, and then not been able to be saved in
 the database to run again.

 You are correct that (in our case) we do not see evidence of our cron jobs
 not being re-scheduled ("deleted" as you say but that's not what's
 happening, the job has run so a new job has to be scheduled and that
 fails) because our application checks for the existence of the schedule
 and adds it if it doesn't exist (in a custom plugin, not `functions.php`)
 ...

 {{{
             if ( !wp_next_scheduled('my_cron_nightly') ) {

                 wp_schedule_event( strtotime('06:00:00 Europe/London'),
 'daily', 'my_cron_nightly' );

             }
 }}}

 Whilst this is an irritating problem when it happens sporadically on sites
 (as with the `could_not_set` issue) the missing schedule is picked up
 quickly and added again; when ''your'' cron jobs are set to run **every**
 minute and your database backup (which locks the database) runs for
 several minutes, it's going to be much more prevalent and 100% likely to
 occur and 100% likely that schedules are not added as required.

 It is possible to change your database tables to use InnoDB instead of
 MyISAM, we do it all the time for our clients. Make sure you have a backup
 though! :)

 That **may** be the solution to your problem ... although running cron
 every minute is still not a good idea. In my opinion.

 Oliver

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