Rasplit compression support

[Carter Bullard]

Hey Matt,
I can't recreate your condition on any machines I have, and if you 
look at the code, and I think the debug output shows this, we are doing the
waitpid() needed to harvest the zombies, so I don't know how to
proceed.  If you want to provide me with access to the machine
I'll be happy to try to debug the problem.

This problem could be as simple as a poor PATH definition for the script.
Do you have a PATH definition or full path specification for commands
called in the script?

Carter

On Dec 9, 2009, at 11:43 AM, Matt Sheridan wrote:

> 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/20091210/3671c67d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20091210/3671c67d/attachment.bin>