Mailing List Archive: mod_backhand: Wackamole

Segfault when running wackamole in foreground

Index | Next | Previous | View Threaded

matthew at bytemark

Sep 6, 2003, 7:44 AM

Post #1 of 5 (773 views)
Permalink

Segfault when running wackamole in foreground

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

I was very pleased to find Wackamole yesterday though would have been
slightly more pleased for someone to have told me about it before I'd
reimplemented half of it already :-)

My first project was to get it running between two machines in our office
and check that everything worked as advertised. Now since I like to control
my daemons with daemontools (http://cr.yp.to/daemontools.html) rather than
rely on programs' own inbuilt backgrounding capabilities or tedious init
scripts, I tried to run wackamole in the foreground by turning on debugging
output. Relevant program versions:

Debian 3.0 (stable)
Linux 2.4.20 (a Redhat kernel)
spread 3.17.1
wackamole 2.0.0

My spread.conf looks like this:

Spread_Segment 127.0.0.255:4803 {
localhost 127.0.0.1
}

Spread_Segment 192.168.0.253:4803 {
factotum 192.168.0.253
cc 192.168.0.1
}

And my wackamole.conf looks like this (on factotum at least):

Spread = 4803
SpreadRetryInterval = 5s
Group = officetest
Control = /var/run/wack.it

Prefer None

VirtualInterfaces {
{ eth0:192.168.0.11/24 }
}

Notify {
eth0:192.168.0.0/24 throttle 128
arp-cache
}

balance {
AcquisitionsPerRound = all
interval = 4s
}

mature = 5s

Unfortunately this causes it to segfault and keep hold of the IP address
which I have to delete with "ip addr delete ...". It's output looks like
this:

# /usr/local/sbin/wackamole -d -c wackamole.conf
[snip banner]
connecting to 4803
Clean_up called
Dequeued arp spoof notifier.
No such interface
SP_connect: connected with private group(18 bytes): #wack8071#factotum

Sending 4 local arp entries
Sending 4 local arp entries
Adding 192.168.5.3 to the shared arp cache
Adding 192.168.0.77 to the shared arp cache
Adding 192.168.0.1 to the shared arp cache
Adding 192.168.0.128 to the shared arp cache
UP: eth0:1:192.168.0.11/255.255.255.0
Dequeued arp spoof notifier.
Queued arp spoof notifier for virtual entry.
Count: -1
Count: 0
Re-queued arp spoof notifier for virtual entry.
Segmentation fault

According to gdb this happens in the spread library, events.c line 607:

temp_ptr = Time_queue;
Time_queue = Time_queue->next;
Alarm( EVENTS, "E_handle_events: exec time event \n");
#ifdef TESTTIME
Alarm( DEBUG, "Events: TimeEv is %d %d late\n",tmp_late
#endif
temp_ptr->func( temp_ptr->code, temp_ptr->data ); // segfault here
dispose( temp_ptr );
#ifdef BADCLOCK
Now = E_add_time( Now, mili_sec );
clock_sync++;

Now this is relatively minor practical problem since by running wackamole in
the background, it appears to work without segfaulting. But it does seem a
very curious bug to happen only after forking has occurred, since just
commenting out the fork in wackamole.c causes this to happen. Any ideas how
to get round this so I can supervise the process properly?

- --
Matthew Bloch Bytemark Hosting
tel. +44 (0) 8707 455026
http://www.bytemark-hosting.co.uk/
Dedicated Linux hosts from 15ukp ($26) per month
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/WfKzT2rVDg8aLXQRAvrMAJwP5yO2CHUn/fF+LGGYUwSYgLjNvwCfeHgw
KBlPd2KiT+Uo7HkcME0xf4k=
=lWbi
-----END PGP SIGNATURE-----

caudy at jhu

Sep 6, 2003, 8:54 AM

Post #2 of 5 (723 views)
Permalink

Segfault when running wackamole in foreground [In reply to]

Hi! I don't know about why Wackamole is segfaulting, although I'll look
into it if it continues as a problem for you. My concern is that your
spread.conf seems incorrect, which might cause wackamole to behave in an
odd manner.

The sample.spread.conf often causes confusion about this, but a
localhost segment should only be included in the configuration if its
the only segment (which only makes sense if you're using only one
machine). The second segment, which should be the only one as far as I
understand your configuration, doesn't have a broadcast or multicast
address, but rather the address of one of the two hosts. I'm not sure
what Spread's response to this would be, but it might run and simply try
to communicate. You should replace the address with either the
broadcast address 192.168.0.255, or a multicast address (in the range
224.0.0.0 through 239.255.255.255, excluding some reserved addresses).

> My spread.conf looks like this:
>
> Spread_Segment 127.0.0.255:4803 {
> localhost 127.0.0.1
> }
>
> Spread_Segment 192.168.0.253:4803 {
> factotum 192.168.0.253
> cc 192.168.0.1
> }
>

On a side note, you might want to change this when you stop using
Wackamole only for tests. There should be discussions on the subject in
the list archives.

> mature = 5s

Good luck,
Ryan

--
Ryan W. Caudy
Center for Networking and Distributed Systems
Department of Computer Science
Johns Hopkins University

matthew at bytemark

Sep 6, 2003, 10:36 AM

Post #3 of 5 (730 views)
Permalink

Segfault when running wackamole in foreground [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Sep 06, 2003 at 11:54:25AM -0400, Ryan Caudy wrote:
> Hi! I don't know about why Wackamole is segfaulting, although I'll look
> into it if it continues as a problem for you. My concern is that your
> spread.conf seems incorrect, which might cause wackamole to behave in an
> odd manner.

Thanks for pointing that out-- I was seeing some odd ICMP redirects which
have now stopped happening. Will check out the "mature time" discussion
earlier, but I think I know what you're getting at.

Unfortunately it didn't change the segfaulting behaviour when running in the
foreground; I will try it on OpenBSD later to see if that behaves the same
way. It's only a problem in that: 1) it makes me worry that wackamole may
keel over while managing our routers' IP addresses, though presumably this
list's experience can tell me otherwise, and 2) I can't supervise the daemon
the way I'd like. The main thing is that it works, but if you have the time
to look into it that would be great :)

cheers,

- --
Matthew Bloch Bytemark Hosting
tel. +44 (0) 8707 455026
http://www.bytemark-hosting.co.uk/
Dedicated Linux hosts from 15ukp ($26) per month
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/WhsKT2rVDg8aLXQRAnHTAJ0eUnY9WfdPNfudfRyqqpIVEDf2ZgCfXk1p
5reUffYj5LLLDNKTJtAF+iU=
=Y+FT
-----END PGP SIGNATURE-----

matt at box

Oct 2, 2003, 5:33 PM

Post #4 of 5 (729 views)
Permalink

Re: Segfault when running wackamole in foreground [In reply to]

--On Thursday, October 02, 2003 08:27:31 PM -0400 Theo Schlossnagle
<jesus[at]omniti.com> wrote:

>
> On Thursday, Oct 2, 2003, at 19:15 US/Eastern, Matthias Weidle wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Sat, Sep 06, 2003 at 11:54:25AM -0400, Ryan Caudy wrote:
>>>> Hi! I don't know about why Wackamole is segfaulting, although I'll
>>>> look
>>>> into it if it continues as a problem for you. My concern is that
>>>> your
>>>> spread.conf seems incorrect, which might cause wackamole to behave
>>>> in an
>>>> odd manner.
>>>
>>> Thanks for pointing that out-- I was seeing some odd ICMP redirects
>>> which
>>> have now stopped happening. Will check out the "mature time"
>>> discussion
>>> earlier, but I think I know what you're getting at.
>>>
>>> Unfortunately it didn't change the segfaulting behaviour when running
>>> in
>>> the foreground; I will try it on OpenBSD later to see if that behaves
>>> the
>>> same way. It's only a problem in that: 1) it makes me worry that
>>> wackamole may keel over while managing our routers' IP addresses,
>>> though
>>> presumably this list's experience can tell me otherwise, and 2) I
>>> can't
>>> supervise the daemon the way I'd like. The main thing is that it
>>> works,
>>> but if you have the time to look into it that would be great :)
>>
>>
>> i dunno if it is breaking other things but i have experienced the very
>> same problem with segfaulting and i was able to fix that after
>> compiling wackamole without thread support. i suppose the
>> glibc/threadlib is to blame in that case ...
>
> I believe that is a stack space issue. The release version of wackamole
> requires and inordinately large stack size. While that might be common
> in unithread applications, it isn't in multithreaded applications. I
> think the CVS version has this problem fixed -- I'd love to know if
> people still see the same problems with CVS HEAD.

i would really love to try the latest HEAD of wackamole if only i could
login to the cvs server ...

$ cvs -d :pserver:anonymous[at]cvs.omniti.com:/data/cvs login
Logging in to :pserver:anonymous[at]cvs.omniti.com:2401/data/cvs
CVS password:
cvs [login aborted]: connect to cvs.omniti.com(66.80.117.4):2401 failed:
Connection timed out

anything wrong with it?

cheers,
-- matt.

>
> // Theo Schlossnagle
> // Principal Engineer -- http://www.omniti.com/~jesus/
> // Postal Engine -- http://www.postalengine.com/
> // Ecelerity: fastest MTA on earth
>
>
> _______________________________________________
> wackamole-users mailing list
> wackamole-users[at]lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/wackamole-users

jesus at omniti

Oct 2, 2003, 5:59 PM

Post #5 of 5 (732 views)
Permalink

Re: Segfault when running wackamole in foreground [In reply to]

--Apple-Mail-12-936201143
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed

On Thursday, Oct 2, 2003, at 20:33 US/Eastern, Matthias Weidle wrote:
> --On Thursday, October 02, 2003 08:27:31 PM -0400 Theo Schlossnagle
> <jesus[at]omniti.com> wrote:
>> On Thursday, Oct 2, 2003, at 19:15 US/Eastern, Matthias Weidle wrote:
>>> i dunno if it is breaking other things but i have experienced the
>>> very
>>> same problem with segfaulting and i was able to fix that after
>>> compiling wackamole without thread support. i suppose the
>>> glibc/threadlib is to blame in that case ...
>>
>> I believe that is a stack space issue. The release version of
>> wackamole
>> requires and inordinately large stack size. While that might be
>> common
>> in unithread applications, it isn't in multithreaded applications. I
>> think the CVS version has this problem fixed -- I'd love to know if
>> people still see the same problems with CVS HEAD.
>
>
> i would really love to try the latest HEAD of wackamole if only i
> could login to the cvs server ...
>
> $ cvs -d :pserver:anonymous[at]cvs.omniti.com:/data/cvs login
> Logging in to :pserver:anonymous[at]cvs.omniti.com:2401/data/cvs
> CVS password:
> cvs [login aborted]: connect to cvs.omniti.com(66.80.117.4):2401
> failed: Connection timed out
>
> anything wrong with it?

cvs.omniti.com doesn't run anon cvs. But commedia.cnds.jhu.edu does.
And on the backhand/wackamole page the CVSROOT is:

:pserver:anonymous[at]commedia.cnds.jhu.edu:/storage/cvs

That wasn't working though. Server upgrade broke the chroot. It is up
now:

cvs -d :pserver:anonymous[at]commedia.cnds.jhu.edu:/storage/cvs login
<no password>
cvs -d :pserver:anonymous[at]commedia.cnds.jhu.edu:/storage/cvs co
wackamole

// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on earth

--Apple-Mail-12-936201143
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
charset=US-ASCII

On Thursday, Oct 2, 2003, at 20:33 US/Eastern, Matthias Weidle wrote:

<excerpt>--On Thursday, October 02, 2003 08:27:31 PM -0400 Theo
Schlossnagle <<jesus[at]omniti.com> wrote:

<excerpt>On Thursday, Oct 2, 2003, at 19:15 US/Eastern, Matthias
Weidle wrote:

<excerpt>i dunno if it is breaking other things but i have experienced
the very

same problem with segfaulting and i was able to fix that after

compiling wackamole without thread support. i suppose the

glibc/threadlib is to blame in that case ...

</excerpt>

I believe that is a stack space issue. The release version of
wackamole

requires and inordinately large stack size. While that might be common

in unithread applications, it isn't in multithreaded applications. I

think the CVS version has this problem fixed -- I'd love to know if

people still see the same problems with CVS HEAD.

</excerpt>

i would really love to try the latest HEAD of wackamole if only i
could login to the cvs server ...

$ cvs -d :pserver:anonymous[at]cvs.omniti.com:/data/cvs login

Logging in to :pserver:anonymous[at]cvs.omniti.com:2401/data/cvs

CVS password:

cvs [login aborted]: connect to cvs.omniti.com(66.80.117.4):2401
failed: Connection timed out

anything wrong with it?

</excerpt>

cvs.omniti.com doesn't run anon cvs. But commedia.cnds.jhu.edu does.
And on the backhand/wackamole page the CVSROOT is:

<fontfamily><param>Lucida Grande</param>:pserver:anonymous[at]commedia.cnds.jhu.edu:/storage/cvs </fontfamily>

That wasn't working though. Server upgrade broke the chroot. It is
up now:

cvs -d
<fontfamily><param>Lucida Grande</param>:pserver:anonymous[at]commedia.cnds.jhu.edu:/storage/cvs
login

<<no password>

cvs -d :pserver:anonymous[at]commedia.cnds.jhu.edu:/storage/cvs co
wackamole</fontfamily>

// Theo Schlossnagle

// Principal Engineer -- http://www.omniti.com/~jesus/

// Postal Engine -- http://www.postalengine.com/

// Ecelerity: fastest MTA on earth

--Apple-Mail-12-936201143--

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com