guys- i just put a new snapshot of 2.6.0 out at http://matt-massie.com/ganglia/
here are the changes... the execution tools are back in the distribution now. i tracked down the bug... the native posix interface in the newer redhat kernels is buggy (especially when it comes to handling semaphores). luckily, the linux kernel developers knew they might break things. if you set LD_ASSUME_KERNEL to "2.2.5" before starting gexecd and gexec everything works like a charm. a group in the computer science department at university of washington comfirmed the workaround. (i also had to update some of the openssl code). there is a new configuration file syntax for gmond "channels". in the last snapshot, we used send_channels and receive_channels. that is gone now in favor of a more flexible and long-term solution. the new syntax looks like this <Channel> address 239.2.11.71 port 8649 interfaces eth0 action send_receive ttl 4 </Channel> <Channel> address 192.168.0.45 port 6667 action send </Channel> there are five attributes for a channel: address, port, interfaces, ttl and action (which will likely be changed to actions). address is the ip address/name of the multicast or unicast address (the default is 239.2.11.71). port is the port to send receive or send/receive on (default is 8649). interfaces is a list of interfaces to send/receive on (default is to let the kernel decide a single interface). you can also set the interfaces to "all" which will cause gmond to perform actions (send/receive/s&r) on each and every interface on the machine. ttl is the time-to-live for the messages. currently this only has meaning for a multicast channel. i'll take about this later in the message. default is 1. action (any better ideas for what to call this? maybe "flags?") currently can be set to "send", "receive" or "send_receive".. but in the future we will have "forward" or "bounce" as well. (btw, i'm going to change this attribute to be list instead of a string.. it will be a list of actions) i'll explain. later on the message format will be updated to allow message incapsulation. this will allow host A to send data on behalf of host B. for example, say i have two clusters of machines on private networks. each cluster has a single multi-homed machine (say a frontend). all hosts each cluster would multicast on the default ganglia channel and it would be collected on the frontends. the frontends would then bounce/forward the information on another gmond. <Channel> address 239.2.11.71 port 8649 interfaces eth1 # my private network ttl 1 action receive_send forward forward_address 3.4.5.6 # a unicast route forward_port 6668 </Channel> this configuration tells gmond to listen to the private network traffic and forward it on to host 3.4.5.6 as it receives data. the TTL would have meaning in the unicast realm as well.. each time a gmond receives data it will decrement the TTL for the encapsulated message. this means you could forward data up multiple levels in the hierarchy if you want. i've changed gmetad as well. gmetad is now using thread pools. this means that instead of spinning off a thread for each data_source there is a fixed amount of worker threads working to pull data from each data_source. this is much more efficient and manageable. i think if you take a look at the new code you'll see that it's much cleaner and more manageable. i'm going to be focusing more on the rrd problems in gmetad next. i think i have a new approach .. details later. there is so much more i have to talk about but i can only type so fast and i'm looking forward to going home for the weekend. hope you guys have a great weekend. -matt
