On 4/19/07, Junko IKEDA <[EMAIL PROTECTED]> wrote:
Hi,
This is not a serious problem but I just take notice of this, so please let
me know whether this is a common behavior for Heartbeat or not, if you know
anything about it.
There are two nodes, a virtual IP (IPaddr) is running on one of them.
On 4/18/07, 池田淳子 <[EMAIL PROTECTED]> wrote:
Hi Andrew,
I'm sorry to ask a lot of questions at a time...
Let's just put it this way.
I just try to replicate the circumstances that is a temporary blackout of
the interconnect LAN.
When some nodes resolve their Split-Brain,
(1) If the LAN recovers b
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew
Beekhof
> Sent: Thursday, April 19, 2007 4:29 PM
> To: High-Availability Linux Development List
> Subject: Re: [Linux-ha-dev] transition graphs during fail-over process
>
> On 4/19/07, Junko IKED
On 4/19/07, Junko IKEDA <[EMAIL PROTECTED]> wrote:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew
Beekhof
> Sent: Thursday, April 19, 2007 4:29 PM
> To: High-Availability Linux Development List
> Subject: Re: [Linux-ha-dev] transition graphs
If for some reason the file being scanned is malformed, or
overflows one of the feilds for some reason, scanf will neither
return EOF nor fill in all of its parameters correctly. In the
case that I observed this resulted in an endless loop.
This simple fix just bails out in this case.
Index: lha-
devname is passed to scanf which will fill in a string of up
to 20 bytes + trailing '\0'. So make devname 21 bytes long accordingly.
Index: lha-STABLE_1_2-ipv6addr/heartbeat/resource.d/IPv6addr.c
===
--- lha-STABLE_1_2-ipv6addr.orig/h
This check seems to cause an error on Debian Etch and as it has
been removed from the 2.0 tree it seems safe enough to do it here too.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417835
diff -r ee4486ddff77 heartbeat/resource.d/IPv6addr.c
--- a/heartbeat/resource.d/IPv6addr.c Thu Nov 30 11
while reading over the IPv6addr code I notices that there is an overrun in
find_if() in the case where the prefix is 128. In this case,
mask.s6_addr[16] will be accessed twice, but that array only
has 16 elements.
The patch below takes the simple approach of just treating 128 as a corner
case and
Hi,
last week I posted about some problems that I found while poking around
IPv6addr in the unstable tree. I also poked around the lha-STABLE_1_2 tree
and the subsequent patches are for bugs that I found and think warrant
inclusion in the stable tree. That is I think they fall into one
of the fol
zero outpack to prevent a potential information leak from
IPv6addr into the icmp packets that it sends.
Index: lha-STABLE_1_2-ipv6addr/heartbeat/resource.d/IPv6addr.c
===
--- lha-STABLE_1_2-ipv6addr.orig/heartbeat/resource.d/IPv6addr.
On 4/19/07, Junko IKEDA <[EMAIL PROTECTED]> wrote:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew
Beekhof
> Sent: Thursday, April 19, 2007 4:47 PM
> To: High-Availability Linux Development List
> Subject: Re: [Linux-ha-dev] "start-delay" par
Hi,
while looking into the source due to our recent problems, I see there are
several macros, which could be replaced by static (inline) functions, e.g. in
GSource.c.
Is there a reason to use macros? Do you mind if I convert this into functions?
Thanks,
Bernd
--
Bernd Schubert
Q-Leap Networ
On 4/19/07, Bernd Schubert <[EMAIL PROTECTED]> wrote:
Hi,
while looking into the source due to our recent problems, I see there are
several macros, which could be replaced by static (inline) functions, e.g. in
GSource.c.
Is there a reason to use macros? Do you mind if I convert this into functio
On Thu, 19 Apr 2007, Bernd Schubert wrote:
> while looking into the source due to our recent problems, I see there
> are several macros, which could be replaced by static (inline)
> functions, e.g. in GSource.c.
>
> Is there a reason to use macros? Do you mind if I convert this into
> functions?
On Thursday 19 April 2007 14:10:45 David Lee wrote:
> On Thu, 19 Apr 2007, Bernd Schubert wrote:
> > while looking into the source due to our recent problems, I see there
> > are several macros, which could be replaced by static (inline)
> > functions, e.g. in GSource.c.
> >
> > Is there a reason t
i dont see any reason _not_ to make these particular macros
functions... they're only used in the c-file that defines them and not
being used to break out of loops or anything.
On 4/19/07, Bernd Schubert <[EMAIL PROTECTED]> wrote:
On Thursday 19 April 2007 14:10:45 David Lee wrote:
> On Thu, 19
On Thursday 19 April 2007 14:37:47 Andrew Beekhof wrote:
> i dont see any reason _not_ to make these particular macros
> functions... they're only used in the c-file that defines them and not
> being used to break out of loops or anything.
Great, I will come up with a proper patch in a week or so
Hello,
Recently I introduced a bug which today I fixed, but the whole
thing left unpleasant taste. The bug gets excercised in case
ha_logd has been setup to log through syslog. The problem is that
there are multiple programs logging with different tags (such as
heartbeat,cib,crm) whereas syslog al
On Thu, Apr 19, 2007 at 09:07:17PM +0200, Dejan Muhamedagic wrote:
> Hello,
>
> Recently I introduced a bug which today I fixed, but the whole
> thing left unpleasant taste. The bug gets excercised in case
> ha_logd has been setup to log through syslog. The problem is that
> there are multiple pro
On Thu, Apr 19, 2007 at 02:37:47PM +0200, Andrew Beekhof wrote:
> i dont see any reason _not_ to make these particular macros
> functions... they're only used in the c-file that defines them and not
> being used to break out of loops or anything.
I'll throw my 2c worth, which is that I also think
On Thu, Apr 19, 2007 at 05:19:23PM +0900, Horms wrote:
> Hi,
>
> last week I posted about some problems that I found while poking around
> IPv6addr in the unstable tree. I also poked around the lha-STABLE_1_2 tree
> and the subsequent patches are for bugs that I found and think warrant
> inclusion
21 matches
Mail list logo
