[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 j3gaming):

 Replying to [comment:9 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.


 Just looked, every table is running InnoDB


 > 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.

 Yes, it looks like I need to have the crons added via code. That way if
 they are ever missing from the crons option, they are immediately re-
 added. I think this type of code has been covering up this problem for a
 long time. Using a plug-in to add/remove crons (like WP Control) is the
 only way to experience them being deleted.

 Can you do a test for me? Install WP Control and add a cron to it. Next
 time you get a could_not_set, can you see if it's still there?


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

 It's a cron for sending emails, so I would like them to go in a timely
 manner!

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