The PhoneBoy Blog


Simplifying Telecom, Mobile Phones, Gadgets, Health, and More!

FireWall-1 FAQ: Log Buffer Message Queue Full or Records Lost

Please note: This content was from when I was operating my FireWall-1 FAQ site, which I stopped operating in August 2005. For some reason people still have links to this stuff on the Internet that people are still clicking on.


I am making this information available again AS IS. Given how old this information is, it is likely wildly inaccurate. I have no plans to update this information.


If you're still running versions of Check Point VPN-1/FireWall-1 where this information is still relevant to you, do yourself a favor and upgrade to a more recent release. If you happen to be running a current release and the information is useful, it's by happenstance :)


The error messages “log buffer message queue full” or “log records lost” generally occur on some installations of FireWall-1 3.0b and FireWall-1. What this means (particularly if this message does not occur at startup) is that the kernel memory buffer used to store entries to log to disk has overflowed. In HP/UX and Solaris, the STREAMS message queue is used first, then the kernel memory buffer. There are some strategies for addressing the problem indirectly:

  1. Some on the FireWall-1 Mailing List have suggested the following FAQ solved their problem along with increasing the amount of physical memory: fw: halloc: memory exhausted
  2. Others on the list have suggested increasing the number of connections that FireWall-1 can handle will also help. See Increasing Number of Connections Allowed by FireWall-1.
  3. Reduce the amount of traffic being logged. This includes “long” and “accounting” entries.
  4. Increase the “Excessive Log Grace Period,” which prevents duplicate entries within n seconds from being added to your log file.
  5. Renice the fwd process to a higher priority (e.g. give it a negative priority). This will cause the logging daemon to process packets faster. It is suggested that you do not renice the process any lower than -5 as it will have a negative effect on your firewall’s overall performance.

In FireWall-1 4.1 SP1 and later, you can set a kernel variable to resolve this. fw_msg_q_max is used on Solaris and HP/UX (the default is 512 on 4.1, 1024 in NG), which is a variable that controls how big the log queue is (in number of messages). On other platforms, the variable is fw_logalloc in 4.1, fw_log_bufsize in NG. These variables are set in bytes (default is 81920 bytes).

To modify this parameters, use the following instructions based on your platform. Solaris and HP/UX will show changes to 5120 (0x1400). The other example show setting this to 512k-bytes (or 0x80000)

On Solaris machines, add the following line to the bottom of the /etc/system file and reboot:

`set fw:fw_msg_q_max=0x1400`

To increase the limit without rebooting on Solaris, you can do the following:

`# echo "fw_msg_q_max/W1400" | adb -k -w`

On HP-UX 10 machines use the following command and reboot the gateway:

`# echo "fw_msg_q_max?W1400" | adb -w /stand/vmunix`

On AIX machines use the following commands:

`# echo "fw_logalloc?W80000" | adb -w /etc/drivers/fw.ext`
`# fwstop`
`# fwstart`

On an IPSO system (VPN-1 Appliance or Nokia IPxxx), you will need to get the ‘modzap’ utility from Resolution 1261 in Nokia’s Knowledge Base. You can then use the following command line to modify the fw_logalloc parameter and reboot:

`# modzap _fw_logalloc $FWDIR/boot/modules/fwmod.o 0x80000`

On Linux, you add the following to $FWDIR/boot/modules/fwkern.conf and restart FireWall-1:

`fw_msg_q_max=0x80000`

#Cybersecurity Evangelist, Podcaster, #noagenda Producer, Frequenter of shiny metal tubes, Expressor of personal opinions, and of course, a coffee achiever.