Snort Crashing During Start-up ( fpcreate)

  • New User of PFsense with Snort, and having problems with Snort. Searched High and Low,  and haven't been able to find anyone else having this problem - Odd that, since I'm just set-up PFSense about a month ago, and don't think I'm doing anything exotic. And is probably due to some misunderstanding on my part.

    Snort package: pkg v. 1.33
    Using  Snort, Emerging Threat Rule sets
    Memory: AC
    Interface: WAN

    Upon Start-up I get the following Error:

    FATAL ERROR: fpcreate.c(1521) Failed to compile port group patterns.

    Log Context:

    Aug 28 15:39:41 snort[56377]: FATAL ERROR: fpcreate.c(1521) Failed to compile port group patterns.
    Aug 28 15:39:41 snort[56377]: FATAL ERROR: fpcreate.c(1521) Failed to compile port group patterns.
    Aug 28 15:37:14 SnortStartup[56379]: Interface Rule START for 0_22704_re0…
    Aug 28 15:37:14 snort[56377]: Decoding Ethernet on interface re0
    Aug 28 15:37:14 snort[56377]: Decoding Ethernet on interface re0
    Aug 28 15:37:14 snort[56377]: Writing PID "56377" to file "/var/log/snort/run/"
    Aug 28 15:37:14 snort[56377]: Writing PID "56377" to file "/var/log/snort/run/"

    I can work around the problem by deselecting various rule categories, but I don't know why that is.

    Can someone clue me up?

  • Darn, thought I covered all of the pre-reqs, apologies.

    pfSense Version:

    built on Sun Dec 6 23:21:36 EST 2009
    FreeBSD 7.2-RELEASE-p5 i386

    ( Rules updated today, problem has been a hassle since I installed the new version of Snort, three four weeks ago )

    I've worked around this problem by category, not by rule, through trial and crash, one of the stock/unedited categories that if enabled will evoke this fatal error is 'snort_misc.rules' ( is enabled, and not a problem )

    Is there a debug option/flag of some sort that can assist me in identifying which rule of 90 rules defined in that category is the problem?

  • The problem doesn't appear to be just one rule - going through 'snort_misc.rules', I found at least three rules that elicit the crash, rule 505, 507, and 1074. If any one of those is selected, a crash at start-up will occur. I am sure that there are others in this and other categories that will also cause the crash.

    What could be the cause? In the context of Snort what does the error mean?

  • Thanks for the help.

    The pre-processor flags were all enabled.

    Turns out the problems appears to be memory exhaustion.  Accidentally, while searching for debug information, I changed "Config Detection:" to include "debug-print-group-build-details", which turned out to invalidate the preceding values ( duh, the flags aren't cumulative ), giving me the default memory model of AC-BNFA - and everything worked ( initially I thought I was screwed, by Heisenberging the configuration, the problem had gone away ).  I'm now running AC-SPARSEBANDS without even a tremor.

    So my guess here is that it wasn't any rule in particular, but the number and complexity of the rules ( combined with high STREAM5 pre-processor settings? ), that pushed the memory requirement under the AC model to exceed available resources.

    Running Platform:
    Pentium D @ 2.66GHz, 3Gig Mem, 4Gig Swap

    Forgive my ignorance here, but is there a way to increase swap size without ripping everything up?

  • Glad to hear you have it working.

    You have a good machine snort should have no problem running on any setting.
    So, we have to figure this out. Can you try the new search methods that introduced.

    You seem like you know what your doing. So, can you do me a favor and do this for me as I dont have time today.

    Edit your snort.conf, mine is;


    Change the search-method

    from ac to ac-q and start snort manually.

    and see if that fixes it.


  • Will try, need to give a try before expanding the size of my swap disk ( )  Guess I should RTFM before asking dumb questions….

    Anyone considered adding swap space advice to the install swap allocation page, advising larger sizes if you plan on installing some of the more honking packages?

    Back to you tomorrow

  • Using ac-q crashes, same results:

    Aug 30 13:42:16 snort[47158]: FATAL ERROR: fpcreate.c(1521) Failed to compile port group patterns.
    Aug 30 13:39:49 snort[47158]: Decoding Ethernet on interface re0
    Aug 30 13:39:49 snort[47158]: Writing PID "47158" to file "/var/log/snort/run/"
    Aug 30 13:39:49 SnortStartup[47160]: Interface Rule START for 0_22704_re0…
    Aug 30 13:39:49 snort[47158]: PID path stat checked out ok, PID path set to /var/log/snort/run


    config detection: search-method ac-q max_queue_events 5

    Other Preprocessor Settings:

    HTTP server flow depth: 0
    Max Queued Bytes: 5048576
    Max Queued Segs : 6621

    Snort.conf file:
    ( config detection is defined twice, used the user pass-through to over-ride previous value )

  • My next step is to significantly increase the size of my swap space, to say 20gig - and attempt starting up, with significantly more resources available, it should go.

    With significantly larger number of rules, not just the snort-misc rules, I'm currently running at 85% memory usage, and 3% CPU. At snort invocation, that soars to like 75% cpu.

    Can you help me out here? Under AC it appears that fpcreate is compiled ( or just compiles port groups? ), offering high performance in a smaller footprint, then under AC-BNFA. The start-up time using AC-BNFA is seconds, in comparison to the minutes it takes using AC.  Just trying to get a feel for the theory of operation.

  • Thanks for your help gnoel.

    Report back when you added more system swap space.

    I could explain every thing to you but, your going to have to read the snort manual pdf under search-method.
    The pdf is found in the snort src tar file from

    Check your pm.


  • Darn!

    The adding of a honking ( 24gig ) swap file did not solve the problem.

    I am up and running with sparse bands as a memory model.

    What are the possible causes of the failure to compile the port groups? Pretty sure it is memory related ( at 1% CPU, 85% of Main memory, 12% of 4gig Swap ).

Log in to reply