On 18/03/13 01:00, Alan Robertson wrote:
> Well... There's something odd about your logging configuration.
> 
> Message from syslogd@test at Mar 17 23:49:47 ...                              
>                                                              "root@test:~" 
> 23:49 17-Mar-13
>  cma DEBUG: DroneInfo.logjson: JSON text for 
> test.default.jnguyen.uk0.bigv.io/netconfig already processed - ignoring.
> 
> Both the CMA and the nanoprobe send everything of importance goes to
> syslog.  There's some dupication to stdout/stderr - but everything of
> interest should also go to syslog.  That kind of message above comes
> from something like wall. I think you can configure syslog to wall out
> various messages (but why?)

Doesn't happen on Fedora, so I compared the rsyslog.conf settings and
there's one line that's different.

EL6: *.emerg *
F18: *.emerg :omusrmsg:*

Commenting out this line on EL6 gets rid of this output.


> You didn't send the messages fromthe CMA.  Seeing it run with 3 -d
> options should prove insightful.  (Fewer might be enough, but 3 would
> certainly do it).  For reproducing it, it would be cool if you could
> send me the outputs of these commands on whatever machine was running
> the nanoprobe code:
> 
>       /usr/share/assimilation/discovery_agents/tcplisteners
>       /usr/share/assimilation/discovery_agents/tcpclients
>       /usr/share/assimilation/discovery_agents/cpu
>       /usr/share/assimilation/discovery_agents/os
>       /usr/share/assimilation/discovery_agents/arpcache

More logs:

https://jamielinux.com/pub/stderr-cma.txt

https://jamielinux.com/pub/tcplisteners.txt
https://jamielinux.com/pub/tcpclients.txt
https://jamielinux.com/pub/cpu.txt
https://jamielinux.com/pub/os.txt
https://jamielinux.com/pub/arpcache.txt

The nanoprobe is currently running on the same machine (a throwaway VPS)
as the cma.

I also have a Fedora instance on a fairly identical throwaway VPS on the
same network which doesn't seem to choke. The cma does show one error
after the nanoprobe connects though:

MessageDispatcher <type 'exceptions.TypeError'> exception ['NoneType'
object has no attribute '__getitem__'] occurred while handling
[HBSHUTDOWN] FrameSetFrameset from [::ffff:-43.-118.100.-51]:57225

The whole cma -f -d -d -d output here:
https://jamielinux.com/pub/fedora-cma.txt
https://jamielinux.com/pub/fedora-nanoprobe.txt


> DroneInfo.logjson: JSON text for test.default.jnguyen.uk0.bigv.io/arpcache 
> already processed - ignoring.
> DroneInfo.logjson: JSON text for test.default.jnguyen.uk0.bigv.io/OS already 
> processed - ignoring.
> Processing tcpclients JSON data from test.default.jnguyen.uk0.bigv.io into 
> graph.
> Processed tcpclients JSON data from test.default.jnguyen.uk0.bigv.io into 
> graph.
> 
> I would guess it was either the tcpclients  or the tcplisteners JSON
> that triggered the crash (but could also be the cpu command).  It isn't
> likely to be the arpcache or OS command.
> 
>> (Another odd thing is that both cma and nanoprobe output debug messages
>> by default when on EPEL 6 even without passing "-d" option.)
> 
> I'll look into those particular messages.  I could easily have missed
> the if(DEBUG) or equivalent...

(Just wanted to clarify that this only happens on EPEL 6 and not Fedora
so I'm not sure what's going on.)


-- 
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