Am 27.01.2015 um 21:41 schrieb William A. Rowe Jr.:
On Mon, 26 Jan 2015 16:43:29 -0500 Jim Jagielski <j...@jagunet.com> wrote:I'll give the vote another 24 hours... I don't consider the UTC/logging issue enough to hold the release, unless it appears a symptom of a more serious problem, but want to give us some more time to try to get a handle on it.I'd agree. My thoughts on OP's posts, that their specific PHP scripts are modifying the global timezone locale, notably process-by-process, and these are not reset at the end of processing. In the case of the event or worker MPM it's impossible to do this without a thread-local implementation of time.h (as Windows and Netware have long had) while even with prefork, depending on which process handles a given request, this php script will apparently have left the server in one state or another, leading to 'flipping' the timezone from log entry to entry. It's [mostly] harmless. If a given log entry is 'zinged' by a change of the timezone offset in between formatting the zone and formatting the time and the date, this could yield some wild jumps. But as the PHP crew long demoted thread saftey from experimental to deprecated (IIUC), then I'm afraid we simply have to take them at their word. The universally endorsed php processing mechanism is now fcgi.
mod_php with mpm-worker is running without threadsfgci is nice, but it lacks 100% compatibility for <Directory> and <VirtualHost> settings the same way it's possible with mod_php
that makes migration of many hundret virtual hosts with a ton of security specific and fine grained per-host configs a hard to undoable or at least not testable task
signature.asc
Description: OpenPGP digital signature
