On 03/19/2013 01:16 AM, Jamie Nguyen wrote:
> On 18/03/13 19:08, Alan Robertson wrote:
>> This occurs both on the startup and the shutdown message. So, there's
>> something pretty hinky going on here...
>>
>> MessageDispatcher <type 'exceptions.TypeError'> exception ['NoneType' object
>> has no attribute '__getitem__'] occurred while handling [STARTUP]
>> FrameSetFrameset from [::ffff:-43.-118.100.-51]:57225
>>
>> This is certainly strange... I can check the code for things that might
>> cause it format an IP address this way: [::ffff:-43.-118.100.-51]:57225
Fixed.
>> Looks like the original IP addresses involved might be one of these:
>> 213.138.100.205/24 213.138.100.255
>>
>> I can put in test cases for these values and see if they seem to work...
>> The code converts things to IPv6 as soon as it can...
>>
>> *
>> **I take it that none of these messages are going into syslog anywhere?*
>>
>> Because there is some really important stuff not in those outputs -
>> which I kind of assume went into syslog for you like it does for me.
>>
>> Here's an example of what I expect to see but isn't there:
>>
>>
>> In particular the stack traceback is missing. It's delimited by
>> ======== signs -- like this:
>>
>> Mar 3 14:50:08 servidor cma INFO: ======== Begin HBDEAD Message
>> Relationship direction must be an integer value Exception Traceback ========
>>
>> I need to see where the None object came from...
>>
>> Although grabbing stdout and/or stderr is often useful, I assume that I
>> need to operate from syslog for the long term - so that's how it's set
>> up to work.
>
> (NB: All of the below are using hg revision 541.)
>
>
> This is all there is in syslog from starting cma on EPEL
> (CentOS) 6 until it crashes. Not sure where the stack traceback messages
> we expect have disappeared to.
>
> Mar 18 21:31:13 test cma INFO: Listening on: 0.0.0.0:1984
> Mar 18 21:31:13 test cma INFO: Requesting return packets sent to:
> 213.138.103.110:1984
> Mar 18 21:31:13 test cma INFO: TheOneRing created - id = 38
> Mar 18 21:31:13 test cma INFO: Config Object sent to nanoprobes:
> {"cmaport":1984,"cmainit":"0.0.0.0:1984","warntime":3000000,"hbtime":1000000,"outsig":"{SignFrame
> object at
> 0x0x1dd7820}","cmadisc":"213.138.103.110:1984","hbport":1984,"cmafail":"213.138.103.110:1984","deadtime":10000000,"cmaaddr":"213.138.103.110:1984"}
> Mar 18 21:31:13 test cma INFO: Starting CMA version 0.1.0 - licensed
> under The GNU General Public License Version 3
> Mar 18 21:31:20 test nanoprobe[10895]: INFO: CMA address: 224.0.2.5:1984
> Mar 18 21:31:20 test nanoprobe[10895]: INFO: Local address: [::]:48885
> Mar 18 21:31:20 test nanoprobe[10895]: INFO: Starting version 0.1.0:
> licensed under The GNU General Public License Version 3
> Mar 18 21:31:20 test cma INFO: Aliasing 127.0.0.1 to
> [::ffff:213.138.103.110]:48885
> Mar 18 21:31:20 test cma INFO: Aliasing ::ffff:127.0.0.1 to
> [::ffff:213.138.103.110]:48885
> Mar 18 21:31:20 test cma INFO: Aliasing ::1 to
> [::ffff:213.138.103.110]:48885
> Mar 18 21:31:20 test nanoprobe[10895]: NOTICE: Connected to CMA.
> Happiness :-D
> Mar 18 21:31:20 test cma INFO: Drone test.default.jnguyen.uk0.bigv.io
> registered from address [::ffff:213.138.103.110]:48885
> (213.138.103.110:48885)
> Mar 18 21:31:21 test �<31>cma DEBUG: DroneInfo.logjson: JSON text for
> test.default.jnguyen.uk0.bigv.io/netconfig already processed - ignoring.
> Mar 18 21:31:21 test �<28>cma WARNING: Drone
> test.default.jnguyen.uk0.bigv.io is already a member of this ring
> [The_One_Ring] - removing and re-adding.
> Mar 18 21:31:22 test �<31>cma DEBUG: DroneInfo.logjson: JSON text for
> test.default.jnguyen.uk0.bigv.io/arpcache already processed - ignoring.
> Mar 18 21:31:22 test �<31>cma DEBUG: Processing tcpclients JSON data
> from test.default.jnguyen.uk0.bigv.io into graph.
> Mar 18 21:31:23 test cma WARNING: add_tcpipports("::ffff:127.0.0.1"):
> address is local
> Mar 18 21:31:23 test �<31>cma DEBUG: Processed tcpclients JSON data from
> test.default.jnguyen.uk0.bigv.io into graph.
> Mar 18 21:31:23 test cma[10887]: EMERG: Attempt to cast (unknown class)
> pointer at address 0x1edbd30 to ConfigValue (formerly a (unknown class))
>
>
>
>
> The tests seem like they could shed more light. Running testify on CentOS 6:
>
> $ cd cma/
> $ testify -v tests
> tests.cma_test TestCMABasic.test_several_startups ... The CMA read 5
> packets.
> The CMA wrote 25 packets.
> ok in 10.18s
> tests.cma_test TestCMABasic.test_startup ... ok in 0.02s
> tests.cma_test TestTestInfrastructure.test_echo1pkt ... ok in 0.02s
> tests.cma_test TestTestInfrastructure.test_eof ... ok in 0.02s
> tests.cma_test TestTestInfrastructure.test_get1pkt ... ok in 0.02s
> tests.cclass_wrappers_test pyAddrFrameTest.test_constructor ... ok in 0.02s
> tests.cclass_wrappers_test pyConfigContextTest.test_ConfigContext_array ...
> ** ERROR **: Attempt to cast (unknown class) pointer at address
> 0x1d08d10 to ConfigValue (formerly a (unknown class))
This isn't _too_ surprising. This test includes an array - which is a
linked list in 'C'. It's one of least-well tested part of the
ConfigContext code. Of course, it is working in Fedora and in Ubuntu.
I'll try and test this from a CentOS VM in the next few days.
>
> Running testify on Fedora 18:
>
> $ cd cma/
> $ testify tests
> The CMA read 5 packets.
> The CMA wrote 25 packets.
> .............................fail: tests.cclass_wrappers_test
> pyNetAddrTest.test_ipv6_str
> Traceback (most recent call last):
> File "./tests/cclass_wrappers_test.py", line 255, in tearDown
> assert_no_dangling_Cclasses()
> File "./tests/cclass_wrappers_test.py", line 49, in
> assert_no_dangling_Cclasses
> raise AssertionError, "Dangling C-class objects - %d still around" %
> count
> AssertionError: Dangling C-class objects - 1 still around
>
> Ffail: tests.cclass_wrappers_test pyNetAddrTest.test_ipv6_strinit
> Traceback (most recent call last):
> File "./tests/cclass_wrappers_test.py", line 237, in test_ipv6_strinit
> self.assertEqual(str(ipv6), '[::ffff:255.255.255.255]:65535')
> AssertionError: '[::ffff:-1.-1.-1.-1]:65535' !=
> '[::ffff:255.255.255.255]:65535'
>
> F..fail: tests.cclass_wrappers_test pyNetAddrTest.test_toIPv6
> Traceback (most recent call last):
> File "./tests/cclass_wrappers_test.py", line 169, in test_toIPv6
> self.assertEqual(str(ipv4),ipstr)
> AssertionError: '-43.-118.100.-52:57225' != '213.138.100.204:57225'
This should be fixed now. By the way, in it's infinite wisdom, recent
versions of Glib decided that by default you didn't really want debug
messages that your code prints, unless you set the environment variable
G_MESSAGES_DEBUG to "all". Silly me, if I don't want a message, I don't
print it...
--
Alan Robertson <[email protected]> - @OSSAlanR
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
