Rasplit compression support

[Matt Sheridan]

Hi Carter -

I was wondering what your thoughts might be on this moving forward? The
defunct processes continue to pile up.

Not sure if its related, but if I run a basic ra on a file, I am getting
some other process complaints:

ra -r ./argus.2009_12_09_1100.out.gz - host 10.10.10.10
ra[4935]: 11:42:56.648522 ArgusReadStreamSocket (0x41fc) record length is
zero

gzip: stdout: Broken pipe

On Tue, Nov 17, 2009 at 10:51 AM, Matt Sheridan <mattmail5050 at gmail.com>wrote:

>
> I have an update. It seems that what is becoming a zombie is the script
> called by the "-f" option (you may have already figured that out, I just did
> ;)"
>
> I attempted to use the default contrib script included in the clients
> package, and it also zombied.
>
>
> But as you can see:
>
> root      1716 31417  8 10:46 pts/1    00:00:10 rastream -S localhost:561
> -M time 1m -B 10s -f /opt/IDS/argus/etc/rastream-orig.sh -
> root      2057  1716  0 10:47 pts/1    00:00:00 [rastream-orig.s] <defunct>
>
> it was the rastream-orig.sh script, called by the -f option (which is used
> to zip up the files) that zombied. So it is possible that the problem is not
> within rastream, but in the way the called script is handled?
>
>
>
> On Mon, Nov 16, 2009 at 9:32 PM, Peter Van Epp <vanepp at sfu.ca> wrote:
>
>> On Mon, Nov 16, 2009 at 04:38:38PM -0500, Matt Sheridan wrote:
>> > I was able to get it figured out. I admit not being fully versed in my
>> > compile skills :). Adding the .debug to the compile directory was the
>> > clarification that I missed.
>> >
>> > Here are the results from stdout. Zombie processes were created when
>> looking
>> > at ps:
>> >
>> > rastream -S localhost:561 -M time 10m -B 10s -f
>> > /opt/IDS/argus/etc/rastream.sh -w
>> > /opt/IDS/argus/log/\$srcid/argus.%Y_%m_%d_%H%M.out -D1
>> > rastream[14067.a08e7288f12a0000]: 16:03:10.090959 main: reading files
>> > completed
>> > rastream[14067.4019a54100000000]: 16:03:10.091388 Trying 127.0.0.1 port
>> 561
>> > Expecting Argus records
>> > rastream[14067.4019a54100000000]: 16:03:10.091652 connected
>> > rastream[14067.4019a54100000000]: 16:03:10.091768 ArgusGetServerSocket
>> > (0x87df0010) returning 3
>> > rastream[14067.a08e7288f12a0000]: 16:10:15.474102
>> ArgusRunScript(0x87d41010,
>> > 21198c10) filename /opt/IDS/argus/log/
>> 127.0.0.1/argus.2009_11_16_1600.out
>> > rastream[14067.a08e7288f12a0000]: 16:10:15.474201
>> ArgusRunScript(0x87d41010,
>> > 0x21198c10) scheduling  /opt/IDS/argus/etc/rastream.sh -r
>> > /opt/IDS/argus/log/127.0.0.1/argus.2009_11_16_1600.out
>> > rastream[14067.a08e7288f12a0000]: 16:10:15.474240
>> ArgusRunScript(0x87d41010,
>> > 21198c10) returning  /opt/IDS/argus/etc/rastream.sh -r
>> /opt/IDS/argus/log/
>> > 127.0.0.1/argus.2009_11_16_1600.out
>> > rastream[16367.a08e7288f12a0000]: 16:10:16.074641 ArgusRunScript calling
>> > /opt/IDS/argus/etc/rastream.sh -r /opt/IDS/argus/log/
>> > 127.0.0.1/argus.2009_11_16_1600.out
>> > deleting
>> <snip>
>>
>>        While I haven't used rastream (let alone run scripts from it :-)),
>> can
>> you tell what is zombieing? My first guess (although I'm not an expert on
>> zombies either :-)) would be that your script isn't returning a result to
>> rastream which is I think what causes a zombie. It would be instructive to
>> know what the original pid of one of the zombies is (as the pids are
>> showing
>> in the argus debug output, although I don't seem to have left one :-)).
>> That
>> should point to what task is causing the zombie.
>>
>> Peter Van Epp
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20091209/6e49da17/attachment.html>