Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I've recently added Ultimate Cron to an existing project with a number of Cron & Queue tasks. Testing went great in my local dev environment, OS X 10.11, running the built-in Apache service. But when I moved the changes to our Testing environment, running Apache on Debian, my Watchdog log began to very quickly fill up with the following PHP notice:
Notice: ob_end_flush(): failed to delete buffer zlib output compression in ultimate_cron_poorman_page_flush() (line 187 of /var/www/sites/all/modules/contrib/ultimate_cron/ultimate_cron.poorman.inc).
I truncated the watchdog table once, and within the span of five minutes, I ended up with ~150,000 instances of the PHP notice. I'd love to be able to use Ultimate Cron, and would prefer to help out with this issue rather than go roll my own, but I'm not entirely certain what's going on here. If someone can point me in the right direction, I will take a crack at fixing it.
Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | ultimate_cron-conditionally_disable_poormanscron-2700625-6.patch | 988 bytes | deetergp |
| #4 | ultimate_cron-conditionally_disable_poormanscron-2700625-4.patch | 800 bytes | deetergp |
Comments
Comment #2
deetergp commentedAnd the really peculiar thing is that this is coming from functions around poorman's cron, on a system where poorman's cron is disabled. We have a Jenkins instance that runs our cron jobs every 15 minutes, obviating the need for Poorman's.
Comment #3
deetergp commentedI've unravelled one mystery regarding why poormanscron was firing in spite of it seeming disabled. Regardless of what settings you had for Drupal's default poormanscron, when you install Ultimate Cron, it enables its own poormanscron out of the box. Hence the reason why a function from ultimate_cron.poorman.inc was being fired and wreaking havoc on watchdog. Once I discovered its settings page at admin/config/system/cron/settings/poorman and changed the launcher from "Serial" to "--Disabled--", we ceased to see the PHP notice regarding
ob_end_flush()not being able to delete buffers with zlib compression.While this does not address the root cause of the issue, it does at least side-step them for our needs. Going to leave this ticket open.
Comment #4
deetergp commentedI'm submitting a patch that makes the assumption that if a site owner has manually disabled Drupal's poormanscron implementation, there's a good change that they aren't going to want Ultimate Cron's poormanscron implementation automatically enabled by default. This patch checks to see if
cron_safe_thresholdis set to0and if it is, disables UC's poormanscron.Comment #5
deetergp commentedComment #6
deetergp commentedNo sooner than I submitted that last patch, did I discover some issues with it. For whatever reason,
variable_get('cron_safe_threshold')always returns0, regardless of what's actually in thevariabletable. I refactored the patch to usedb_query()instead.Comment #7
mgbellaire commentedLooks like coding style is good, and I did test this on a vanilla Drupal installation where the variable is indeed not in the variables table, so it makes sense why the db_query is there instead of just using variable_get. If this were to be added to the module, I don't see any other cause for concern on the functionality.
Great looking patch, @deetergp!
Comment #8
Chris CharltonCheckout out the patch as well; looks fine.
Comment #10
arnested commentedAdded to the 7.x-2.x branch. Thank you for your contribution!