[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [users@httpd] httpd reload fails due to php72w-mysql package?


> On 17 Aug 2018, at 10:41, Stefaan Vanbillemont <stefaan.vanbillemont@xxxxxxxxx> wrote:
> 
> When we execute the command ‘systemctl reload httpd’ several times after each other

Do you know what that does under the hood?  I'd guess it either wraps or
replaces apachectl on your system and performs restart, probably graceful.

A graceful restart is rather slow: it takes time to complete requests it is serving
rather than abort anything mid-request.  If you restart again while an already-
closing-down-and-orphaned process is still running, you're putting yourself at
high risk of edge-case crashes.

> Backtrace: 

Hehehe.  Verily, JSON is the new XML: let's wrap everything!

> core_backtrace:
> :{   "signal": 11
> :,   "executable": "/usr/sbin/httpd"
> :,   "stacktrace":
> :      [ {   "crash_thread": true
> :        ,   "frames":
> :              [ {   "address": 140274079464508
> :                ,   "build_id": "cb4b7554d1adbef2f001142dd6f0a5139fc9aa69"
> :                ,   "build_id_offset": 547900
> :                ,   "function_name": "__libc_free"
> :                ,   "file_name": "/usr/lib64/libc-2.17.so"
> :                }

Smells of shutdown race condition there (and throughout).  What's it seeking to free?
It's coming from deep in layers of third-party libs, and it even looks as if php/zend
is managing mysql directly rather than using apr_dbd.  There's nothing from any
Apache-related software until:

> :              , {   "address": 140274087330830
> :                ,   "build_id": "89ceb54f2d4d09bff13fc2fe35390934ec9e2581"
> :                ,   "build_id_offset": 103438
> :                ,   "function_name": "apr_pool_clear"
> :                ,   "file_name": "/usr/lib64/libapr-1.so.0.4.8”
> :                }

That's a bizarre filename, and gives no clue what APR version you're using!
A recent stable libapr would be 1.6.x.

> When we remove php72w-mysql package from our server the problem disappears.

Removing php is a fine solution to many problems.  A second-best that might
work for you is to use it in a fastcgi configuration rather than loaded into the server.

-- 
Nick Kew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx