Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 27 replies
  • Answers 1 answer
  • Subscribers 45 subscribers
  • Views 8246 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ips.log filling up disk

Farshid

We have XG210 with SFOS 19.5.4. I've noticed ips.log filling up /var partition till there is no free space on disk and it causes device to boot into fail-safe mode. Stopping IPS service stops log file from growing but when I restart IPS service, this issue occurs again. Switching off IPS Protection button from Intrusion Prevention menu or removing IPS polices from all firewall rules does not resolve this issue and only stopping service stops it. Here is the log that reappears again and again in the log file and causes this issue:

2024-03-03T20:42:03.268400Z [28142]:DAQ:INFO:daq_nmsp.c:2342(daq_nmsp_get_pkt)--> jumbogram read failed. jumbo len: 0 rslot 11 rlen 2048

2024-03-03T20:42:03.268402Z [28142]:DAQ:INFO:daq_nmsp.c:2384(daq_nmsp_get_pkt)--> Exit --> DAQ Error -7

I've tried re-imaging SFOS but it didn't solve the problem. Is there anyway to solve this issue without need to stopping IPS?



This thread was automatically locked due to age.
Parents
  • 0

    We have exactly the same problem on a XGS3300 HA Cluster (SFOS Version 20.0). 

    Suddenly CPU usage on the primary node goes high, more and more network connections going down and ips.log is filling up with the messages:

    DAQ:INFO:daq_nmsp.c:2342(daq_nmsp_get_pkt)--> jumbogram read failed. jumbo len: 0 rslot 11 rlen 2048

    DAQ:INFO:daq_nmsp.c:2384(daq_nmsp_get_pkt)--> Exit --> DAQ Error -7

    Struggling around with support since Dec. 2023 and no solution yet. 

  • 0 in reply to SG001

    Hello,

    Case 07151744 was closed in January after providing the workaround mentioned on NC-128322 (fix on 19.5 MR4 and v20.0 MR1)

    Case 07213100 is currently with GES and is being escalated to the DEV team for further investigation. I can see your Access ID has already been shared with DEV.

    Regards,

     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
Reply Children
  • 0 in reply to emmosophos

    Hello Emmanuel

    I'm also interested in this workaround (NC-128322) provided for this issue and check if it's applicable in my case. I checked Sophos Known Issue List and haven't found it. Where can I found NC-128322? Is it public?

  • 0 in reply to Farshid

    Hello,

    The workaround has already been mentioned by Shrikant.

    Regards,

     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • 0 in reply to emmosophos

    Actually NC-128322 (internal ticket to development, no access to public) looks like it was closed by no response from customer.  I took a quick look at the logs from back then and it looks like someone turned on extra debug logging which caused the log files to fill fast.  Depending on how they turn them on, it can even be automatically on when the service restarts.

    ls /sdisk/tmp/debug.cfg
    ls /var/tmp/debugp.conf

    If either of those files exist, delete them.  You can restart the services (web proxy and ips) but I would reboot the box to be clean.

    The log rotate runs once a minute.  Or rather - find log file over the configured size, renames them, compresses them.  The starts a new times 60 second later to do it again.  In some rare cases with super huge files the compression can take seconds (or even minutes) - but I've only seen this when debug logging was on super verbose in a busy system.

    grep log_rotate /log/csc.log should tell more.

Unfiltered HTML