Wow! What a tool. Takes me back a few years to the pre-gui world, though 
I don't run X on my centris. Thanks for the tip. It may take awhile 
before I sort all of the info that I get from ktrace (or run it with the 
proper settings).

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.

The non-daemon snort completed initialization, opened the alert file in 
/v/l/snort, and then did a gadzillion call breaks w/ returns (with 
occasional mmap and munmap thrown in. 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. Lastly, it writes out (in pieces...I'll 
reassemble) "snort in malloc(): error: brk(2) failed [internal error]", 
then writes to a different fd "->activation->dynamic->alert->pass->log", 
and then gibberish to yet another fd. Lastly, it does a core dump.

jeff

Curt Sampson wrote:

> Try using ktrace on it. You can follow the syscalls, what it reads and 
> writes,
> etc. and see what it might be doing.
>
> You can either attach ktrace directly to the process after it's started
> with the -p option, if you can do it quickly enough, or you may have to
> play around with the options relating to tracing children as well as the
> original process.
>
> cjs