Hi,
> Am 20.05.2015 um 02:06 schrieb Todd Mortimer :
>
> The attached patch fixes a problem I’ve been having with httpd +
> php_fpm + owncloud on 5.7. The patch is against 5.7-release.
Can you try with recent snapshot, and see if issue
still occurs, please?
Development happens in -current.
> Af
The patch is in a turned off machine,
after doing the patch
i contacted directly reyk for the matter,
i d like to push the issue further by not accepting
the socket while the connect didnt succeed when possible.
(The pastebin expire)
Please be a bit patient.
On Sat, May 30, 2015 at 12:35 PM, Th
I noticed that httpd will exit if it attempts to serve a file from
a cd9660 filesystem. This is due to libevent's use of kqueue by
default and kqueue's lack of support for cd9660 filesystems. I'm
not sure if this is the most appropriate fix but the patch below
restricts the server processes from us
this might have been a typo and i can build a kernel
with DRMDEBUG now (failed in radeon_benchmark.c).
-f
--
i got real close to seeing elvis but my shovel broke.
Index: drmP.h
===
RCS file: /cvs/src/sys/dev/pci/drm/drmP.h,v
retrievi
Don’t have tun(4), but applied.
As well as latest carp and bridge patches.
So far no problems, except that I see following in dmesg :
arpresolve: unresolved and rt_expire == 0
but this is probably not related to new diffs.
//mxb
> On 28 maj 2015, at 11:28, Martin Pieuchot wrote:
>
> Replace
> it is possible to remove the inflight var by opening the socket before
> accepting.
> Thus there is no need for guessing if the peer socket can be open,
Where is your diff to demonstrate this?
Show your work. (Or we'll have to make an assumption).
On Sat, May 30, 2015 at 10:27:49AM -0400, sven falempin wrote:
> it is possible to remove the inflight var by opening the socket before
> accepting.
> Thus there is no need for guessing if the peer socket can be open,
How should that work when HTTP headers of the request determine to which
system
it is possible to remove the inflight var by opening the socket before
accepting.
Thus there is no need for guessing if the peer socket can be open,
On Sat, May 30, 2015 at 7:40 AM, Claudio Jeker wrote:
> On Fri, May 22, 2015 at 09:18:29PM +0200, Alexander Bluhm wrote:
> > This breaks relayd wit
On Fri, May 22, 2015 at 09:18:29PM +0200, Alexander Bluhm wrote:
> This breaks relayd with TLS inspection. Moving down the "called
> once" check after the F_TLSINSPECT block fixes the plain SSL case.
> But HTTPS still hangs. I have just commited a test. Try
>
> cd /usr/src/regress/usr.sbin/rela
