My hourly argus data files from time to time freeze up any ra tools that touch them

Claudio Luck cluck at ethz.ch
Fri Sep 24 11:20:35 EDT 2010


Hi

I can confirm that this (also) happens when running an archive over
NFSv3 and works fine instead when using a local XFS storage. I think
there is a different handling of concurrent writes in NFS (v3 at least)
compared to local file-systems (Linux). There must be some assumption in
how the files are written in rasplit that only holds for local
file-systems.


Best regards
Claudio

PS:

> System:  Linux log1 2.6.24-27-sparc64 #1 Mon Feb 22 18:28:03 UTC 2010 sparc64 GNU/Linux
> Paths:    /usr/local/sbin/argus /usr/local/bin/ra /usr/bin/make /usr/bin/gcc /usr/bin/cc
> 
> ARGUS:   Argus Version 3.0.3.16
> RA:      Ra Version 3.0.3.16

> Distributor ID: Ubuntu
> Description:    Ubuntu 8.04.4 LTS
> Release:        8.04
> Codename:       hardy










On Thu, 2010-09-23 at 21:43 +0200, The Branches wrote:
> Carter,
> 
> This issue has been happening to me for some time on several different
> hosts running argus, and I keep on upgrading to the latest dev version
> of argus and argus-clients in hopes of fixing it that way.  I'm using
> argus-3.0.3.16 and argus-clients-3.0.3.17 presently and I just had
> another freeze.  I have racluster and racount operations running every
> few minutes which start piling up and bogging down the server until I
> manually kill them off.  I presume some kind of traffic is resulting
> in a corrupt argus data record that ra tools choke on, though that's
> only a guess.  Any thoughts you might have on this issue would be most
> welcome.  I could probably provide a sample argus data file if you
> like.
> 
> The systems are CentOS 5.5, 32 and 64 bit.  
> 
> Argus runs like this
>     argus -i eth0 -F /opt/nids/sensor/etc/argus.conf -P 561
> and the data is split into hourly files like this
>     rasplit -X -S 127.0.0.1:561 -M time 1h -w /argus/%m/%d/eth0-%H.arg
> -d
> 
> Today the 1pm file (eth0-13.arg) was somehow left in a state my ra
> tools can't handle.  For example, if I run this
>     ra -X -r /argus/09/23/eth0-13.arg -nn
> I get about one screen-full of output and then it freezes (CTRL-C
> works to get out).  The last output record to be printed to the screen
> is only a few seconds after the start of the hour (13:00:09.755082).
> I also tried shutting down all argus daemons and running the ra
> command again to see if some wierd file locking issue was behind it,
> but it locked up the same.  I confirmed with lsof that the data file
> in question was not being interacted with by any other programs.
> 
> I'd sure like to get this one licked.  Maybe my whole approach needs
> some refinement.  I'm all ears.
> 
> Thanks!
> Kevin





More information about the argus mailing list