[wp-trac] [WordPress Trac] #39338: class-wp-hook.php - apply_filters() infinite loop

[WordPress Trac]

#39338: class-wp-hook.php - apply_filters() infinite loop
--------------------------+-----------------------------
 Reporter:  frettled      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Plugins       |     Version:  4.7
 Severity:  critical      |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+-----------------------------

Comment (by jacobcolton):

 Literally just had this email from LiteSpeed:

 Hi Jacob,

 After investigating this, it seems to be an issue with the latest "php-
 litespeed" package, or more specifically the LSAPI version that is used
 within the package.

 In LSAPI 7.4 a feature got introduced to gracefully clean up temp files
 when PHP processes got killed during script execution - this feature got
 introduced to resolve an issue that resulted in big "temp" files in
 certain cases.

 Sadly this feature also seems to have introduced another bug that causes
 PHP processes to hang in some cases, but in other cases, it would result
 in the large error_log files you're experiencing.

 We're aware of the issue and are looking into a fix for this, however, I
 do currently not have an ETA when this fix will be published.

 There is a workaround that can be used temporarily until we have a fix and
 this fix has been pushed by both cPanel and CloudLinux (depending on who
 maintains the EA4 packages on your systems).

 The workaround currently is to do a rollback of the packages to the point
 where it uses LSAPI 7.3, this can be done using `yum history undo`, which
 allows doing a rollback of whole transactions performed by YUM.

 On the system with IP xx.xx.xx.xx, to do the rollback you have to do:

 $ yum history undo 440

 The number 440 is the transaction ID from YUM, this ID can be found by
 doing `yum history`, you'll have to look for an update performed somewhere
 between the 15th of July and now that contains quite a few package updates
 (Altered), on this system the number is 91, but on systems with more PHP
 versions you'll likely see a higher number.

 To be sure you're doing a rollback of the correct transaction ID, you can
 do `yum history info ID` to get info about the packages affected.

 Using `yum history undo` will give you a list of packages that will be
 affected where you have to either accept or deny this change.

 Additionally to prevent EA4 from automatically updating the packages
 again, you have to ensure that RPMUP in /etc/cpupdate.conf are set as
 following:

 RPMUP=never

 If you do this change from WHM, you have to go to Server Configuration ->
 Update Preferences, and find "Operating System Package Updates" and set
 this to "Never Update".

 I've yet to find another workaround that is less annoying than this one,
 but at least this gets the systems to a state where you don't have to sit
 and monitor the disk space constantly.

 When I have an update with an ETA, or if we find another way to make a
 workaround that is simpler, I'll be sure to update the ticket.

 Best Regards,
 LiteSpeed Technologies

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