On Wed, Dec 02, 2009 at 07:41:39PM +, Daniel Pocock wrote:
>
> Therefore, the approach might need to be some combination of the
> solutions. E.g. a configure option that allows people to choose the new
> behaviour or the old behaviour.
-1, this will double our supported paths for almost no
Brad Nicholes wrote:
On 12/2/2009 at 7:21 AM, in message <4b1677e4.8000...@pocock.com.au>,
Daniel
> Pocock wrote:
>
>> I would like gmond to return a non-zero return code if it fails to
>> initialise, e.g. if it is unable to bind or if it is unable to resolve a
>> h
>>> On 12/2/2009 at 7:21 AM, in message <4b1677e4.8000...@pocock.com.au>, Daniel
Pocock wrote:
> I would like gmond to return a non-zero return code if it fails to
> initialise, e.g. if it is unable to bind or if it is unable to resolve a
> hostname mentioned in gmond.conf
>
> Otherwise, the in
Gladish, Jacob wrote:
>
>> -Original Message-
>> From: Daniel Pocock [mailto:dan...@pocock.com.au]
>> Sent: Wednesday, December 02, 2009 6:49 AM
>> To: Carlo Marcelo Arenas Belon
>> Cc: ganglia-develop...@lists.sourceforge.net; Ganglia
>> Subject: Re: [Ganglia-developers] [Ganglia-genera
On Wed, Dec 02, 2009 at 11:48:51AM +, Daniel Pocock wrote:
>
>> fork() doesn't work because the kqueue filehandle is not inherited; using
>> rfork() instead doesn't either because all filehandles are closed by doing
>> exit(0) in the parent and so fails in the same way that changing
>> apr_proc
On Wed, Dec 02, 2009 at 11:17:26AM +, Daniel Pocock wrote:
> Carlo Marcelo Arenas Belon wrote:
>> On Wed, Dec 02, 2009 at 10:36:02AM +, Daniel Pocock wrote:
>>>
>>> Can you try re-enabling kqueue and patching apr to use rfork()?
>>
>> Doesn't work, and fails now on sending of the metrics, b
> fork() doesn't work because the kqueue filehandle is not inherited; using
> rfork() instead doesn't either because all filehandles are closed by doing
> exit(0) in the parent and so fails in the same way that changing
> apr_proc_detach() does when changed to use rfork() instead.
>
I'm not a B
Carlo Marcelo Arenas Belon wrote:
> On Wed, Dec 02, 2009 at 10:36:02AM +, Daniel Pocock wrote:
>
>> Carlo Marcelo Arenas Belon wrote:
>>
>>> but that of course requires a patched version of apr (including
>>> bootstrapping) and is probably not an option, unless we go back
>>> to the dar
On Wed, Dec 02, 2009 at 10:36:02AM +, Daniel Pocock wrote:
> Carlo Marcelo Arenas Belon wrote:
>>
>> but that of course requires a patched version of apr (including
>> bootstrapping) and is probably not an option, unless we go back
>> to the dark ages of including all dependencies statically.
>
Carlo Marcelo Arenas Belon wrote:
> On Wed, Dec 02, 2009 at 01:57:44AM +, Carlo Marcelo Arenas Belon wrote:
>
>> On Tue, Dec 01, 2009 at 10:20:32PM +, Daniel Pocock wrote:
>>
>>> - Can you easily re-compile APR with a different poll implementation? I
>>> think you can change it f
On Wed, Dec 02, 2009 at 01:57:44AM +, Carlo Marcelo Arenas Belon wrote:
> On Tue, Dec 01, 2009 at 10:20:32PM +, Daniel Pocock wrote:
> > - Can you easily re-compile APR with a different poll implementation? I
> > think you can change it from configure.
>
> Which option?, --enable-other-
On Tue, Dec 01, 2009 at 10:20:32PM +, Daniel Pocock wrote:
>
> - Could it be a security issue? Can you try disabling setuid? It
> appears that listen channels are only set up after setuid, but maybe
> there is something else.
still reproducible with setuid = off
> - Have you tried diffe
>>> At least a revert would be needed for 3.1 as this accounts for a regression
>>> but haven't done so either waiting for you to first revert it on trunk and
>>> then decide on how to proceed from there depending on how critical this
>>> feature was for the release.
>>>
>>>
>> I agree t
On Mon, Nov 30, 2009 at 01:29:34PM +, Daniel Pocock wrote:
> Carlo Marcelo Arenas Belon wrote:
>>
>> Your call, eventhough a fix for this feature will be probably preferred as
>> there is nothing special about the BSD for them to be affected and it might
>> be that the problem is therefore more
Carlo Marcelo Arenas Belon wrote:
> On Mon, Nov 30, 2009 at 08:12:34AM +, Daniel Pocock wrote:
>
>> Carlo Marcelo Arenas Belon wrote:
>>
>>> On Sun, Nov 29, 2009 at 10:57:01AM +, Carlo Marcelo Arenas Belon wrote:
>>>
>>>
On Tue, Nov 24, 2009 at 06:03:51PM -0800, Berna
On Mon, Nov 30, 2009 at 08:12:34AM +, Daniel Pocock wrote:
>
> Carlo Marcelo Arenas Belon wrote:
>> On Sun, Nov 29, 2009 at 10:57:01AM +, Carlo Marcelo Arenas Belon wrote:
>>
>>> On Tue, Nov 24, 2009 at 06:03:51PM -0800, Bernard Li wrote:
>>>
Please help us test on as many OS/a
Carlo Marcelo Arenas Belon wrote:
> On Sun, Nov 29, 2009 at 10:57:01AM +, Carlo Marcelo Arenas Belon wrote:
>
>> On Tue, Nov 24, 2009 at 06:03:51PM -0800, Bernard Li wrote:
>>
>>> Please help us test on as many OS/archs as possible, as this would go
>>> GA quite immediately ;-)
>>>
On Sun, Nov 29, 2009 at 10:57:01AM +, Carlo Marcelo Arenas Belon wrote:
> On Tue, Nov 24, 2009 at 06:03:51PM -0800, Bernard Li wrote:
> >
> > Please help us test on as many OS/archs as possible, as this would go
> > GA quite immediately ;-)
>
> FreeBSD is not able to return any XML data throu
On Tue, Nov 24, 2009 at 06:03:51PM -0800, Bernard Li wrote:
>
> Please help us test on as many OS/archs as possible, as this would go
> GA quite immediately ;-)
FreeBSD is not able to return any XML data through TCP/8649 (tested with
FreeBSD 8.0 amd64).
DragonFlyBSD fails to build but a 3.2 vers
19 matches
Mail list logo
