[collectd] collectd 4.2.4 network issues with Solaris 8
octo at verplant.org
Thu Feb 14 18:37:59 CET 2008
I'm trying to think hard, but so far it's still a mystery.
On Thu, Feb 14, 2008 at 12:10:06PM -0500, Eric LeBlanc wrote:
> #0 0xffffffff7ae026fc in write_part_number (ret_buffer=0xffffffff796090a0,
> ret_buffer_len=0xffffffff796090a8, type=1, value=1202937442) at network.c:340
> 340 pn.head->type = htons (type);
Could you please provide the contents of the memory pointed to by
ret_buffer and ret_buffer_len? I. e.
Also the contents of the buffer from the beginning would be interesting.
Since it's a (module)global variable you should be able to display it,
too: (don't worry if it looks weird, it's binary data..)
Immediately before the time is added to the buffer, the hostname is
written to there. Could you provide that, too?
I'm afraid that this is a tricky issue, because that part of the code
has worked for thousands of hours on my machines alone. Do you have some
rare situation, however unrelated it might appear at first? Is you
hostname unusually long? Do you run inside a virtual machine? Anything?
What's the output of a normal `df -h' in the command line? Anything
interesting there? (I'm asking because it's the df plugin that's trying
to send anything) Does it still crash if you disable the df plugin?
Is *any* packet send out or is it crashing while constructing the first
packet? It should be possibly to see that in the debugging output. When
compiled with --enable-debug you can set the logfile plugin to log to
and then starting the daemon with the `-f' (don't fork) option.
Florian octo Forster
Hacker in training
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20080214/0f04df62/attachment.pgp
More information about the collectd