Curt Sampson wrote:

> On Sat, 19 Mar 2005, Jeffrey B. Green wrote:
>
>> However, as a tiny update, I did run ktrace, and in the process the
>> whole thing aborted with a core dump (no daemon mode). With -D option
>> given to snort, the tail of the ktrace dump says that it is going into
>> daemon mode and shortly after exits with a 0 exit code.
>
>
> That means you didn't work out the right way to get it to follow the
> child process or processes.
>
>> Finally, it does a call to a break with an error return "-1 errno 12
>> Cannot allocate memory" and immediate call to mmap with same return.
>
>
> Looks like it wants more memory. Hmmm. Not sure why, but you could
> always try giving it more with 'ulimit -d'. But probably it will just
> eat that, too.
>

Well I'll be. It worked. My soft limit on data was at 32K. I upped that 
to 48K and now no aborts. snort must not have a clean check for enough 
memory at some point, may be tied in to the advisories that I saw on the 
snort package page. The snort daemon is now running for much longer than 
in prior tests so I'll assume that fixes it. Thank you very much.

One last question in case you know the answer. I did try to change the 
hard limit on the number of processes, but could not. Is that hard wired 
into the kernel (i.e. process table size at build time) or possibly set 
at boot time and at boot time only? I tried changing it with ulimit and 
sysctl, but no go on both. My guess is at build time since then you 
don't have to working about dynamically modifying the size of the 
process table.

jeff