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

[WordPress Trac]

#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 domainsupport):

 This issue's [[https://wordpress.org/support/topic/cron-unschedule-event-
 error-for-hook/|corresponding topic on the support forum]] has been closed
 to new comments and many replies archived so I will re-iterate everything
 I have learned surrounding the `could_not_set error` notice here for
 completeness and to hopefully spark some kind of path to a resolution.

 The `could_not_set` notice appears when ...

 - **The `$option` parameter of the `update_option()` command is empty**.
   This will never happen (it’s always set, to "cron" when the CRON
 schedule is being saved).
 - **The old option value is the same as the new option value**.
   This suggests the cron job is running more than once (the chances of
 this happening are almost non-existent as they would require the transient
 to be the same which would require the two concurrent requests to have
 been received within the same microsecond).
 - **The database insert query `$wpdb->update()` fails**.

 So I realise it’s a bitter pill … but everything about this issue points
 to the database for whatever reason.

 It also explains why a single solution cannot be found because there are
 several reasons that can cause an issue with the database. Perhaps the
 database has become disconnected ([[comment:24|see this comment]] by
 @galbaras). Perhaps the database is overwhelmed / out of RAM / has too
 many connections. Perhaps something has locked the database up. Who knows,
 the reason will almost certainly be unique to your experience.

 If you’re not seeing anything in your database log … maybe enable more
 verbose logging (if that is possible) and find out exactly what happens
 with the database at the same timestamp as the error notice. For example,
 if the database had disconnected then there may not be an actual error in
 the database log.

 And just because your site has low legitimate traffic, doesn’t mean that
 the database can’t be overwhelmed. All WordPress sites are regularly
 scanned for vulnerabilities by hackers and each scan is an enormous strain
 on a server with hundreds or (more often) thousands of requests that can
 look (and act) like a DDoS attack. We see it all the time and it’s why we
 developed Deny All Firewall to only allow content that exists to be
 requested to mitigate most of these scans and attacks.

 I looked into duplicate CRON causing the issue right at the beginning but
 ruled it out because the transient would require the two requests to be
 fired at exactly the same millisecond. An unlikely scenario that even if
 it were possible would not be so frequently observed.

 However … **transients are stored in the database** … you see where I’m
 going here? 🙂

 If the `doing_cron` transient cannot be stored by one CRON request because
 the database is unavailable (overwhelmed / out of RAM / has too many
 connections, locked, disconnected, etc, etc) then it cannot be checked by
 another CRON request and is another symptom of the same underlying issue …
 namely … the database.

 The problem, as I mentioned above, is that it’s very likely that each
 database issue is different. If I’m right (and I suspect that I am) then
 this entire thread is just discussing the symptom of a completely
 different, multi-facetted problem; namely "any database issue".

 So where do we go from here ... ?

 I would suggest a two-pronged attack on this one:

 1. If your website is experiencing this issue then try to identify your
 database issue perhaps by asking your ISP:
   - How you can gain access to your verbose MySQL error logs?
   - How many concurrent connections are allowed to your database?
   - Can they see if you exceeding this?
   - How much RAM is given to your database?
   - Can they see if you exceeding that?
   - Has your MySQL service had any interruptions?
   - Has your MySQL connection disconnected in PHP?
   - I’m not 100% sure if all of these questions are valid (and it’s not an
 exhaustive list) but if you can get timestamps for anything highlighted
 from them and marry any database issues up to the PHP error notices … you
 may have something you can try to resolve.
 2. WordPress does not seem to identify and / or notify via the logs when
 there are database issues such as those mentioned above. I think there are
 strong grounds to look into some kind of active database error logging
 which would be extremely useful to site owners so they know when their
 database needs attention.

 What do you think?

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