matthew at bytemark
Sep 6, 2003, 7:44 AM
Views: 775
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-----
|
Segfault when running wackamole in foreground
