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
> 
> 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))
aborting...
Aborted (core dumped)




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'

F..........
FAILED.  45 tests / 15 cases: 42 passed, 3 failed.  (Total test time 2.25s)



-- 
Jamie Nguyen


_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/

Reply via email to