- Products
- Learn
- Local User Groups
- Partners
- More
Step Into the Future of
AI-Powered Cyber Security
What's New in R82.10?
Register HereWhen the Agents Attack
A Live Look at Agentic Exposure Validation
AI Security Masters E8:
Claude Mythos: New Era in Cyber Security
CheckMates Go:
CheckMates Fest
The root partition filled up overnight and using du I have narrowed it down to /opt/CPshrd-R80.40/database/postgresql/data/log is taking up the majority of the drive space. Is there a safe way to purge these files and free up the drive space? I searched the support site and this site for this issue but was not able to find anything.
Thanks in advance,
Eric
I assume that you have already resolved the issue. I had similar one, it was resolved by issuing $FWDIR/scripts/postgres_logs_off.sh.
I looked at my /opt/CPshrd-R80.40/database/postgresql/data/ directory and found folder base to contain the big date - but o could not find /opt/CPshrd-R80.40/database/postgresql/data/log ! This is a R80.40 JT 92 SMS. Anyway, it is not a good idea to delete something in a CP installation without good reason and instructions.
Maybe it is the issue from sk166555: PostgresSQL database is very big and continues to grow ? Better involve TAC here...
The database is normal sized it is just the log folder that is excessive. The output from that SK shows it is not that issue.
psql_client cpm postgres -c "select count(*) from dleobjectderef_data where deleted and dlesession=0"
count
-------
858
(1 row)
Digging deeper into it there are several revisions that were created by the Web API when Cloudguard was deployed in NSX yesterday evening so wondering if that may have anything to do with this.
Thanks,
Eric
What about exploring the log folder ? Should also not be an issue to delete logs you do not need....
Still i would suggest to contact TAC - i smell a bug here 8)
Yeah, I will have them open a TAC case, I expanded the root partition this morning to keep us working but it has already grown another 3 Gb today.
Thanks!
I assume that you have already resolved the issue. I had similar one, it was resolved by issuing $FWDIR/scripts/postgres_logs_off.sh.
That was exactly the problem! Someone had enabled debugging in postgres. TAC found this and we turned it off and deleted the logs! I should have come back and posted the solution but thanks for your answer!
HI Sergey,
years go by but Checkpoint still has the same problems. I followed your advice and stopped the Postgres logs. By chance, but I know I ask a lot, do you also remember what you deleted afterwards to free up space?
Thanks.
Hi Fabio,
I don't remember already what I did, too many time passed. Anyway, there is sk60080 that describes common way of managing this type of problems.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 28 | |
| 12 | |
| 6 | |
| 5 | |
| 5 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 3 |
Tue 16 Jun 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point SASE | Internet Access Optimization & Performance TuningThu 18 Jun 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point WAF - The Next Generation of AI powered protectionTue 23 Jun 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point Cloud Firewall | Securing all of your clouds: Art of the possibleTue 16 Jun 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point SASE | Internet Access Optimization & Performance TuningThu 18 Jun 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point WAF - The Next Generation of AI powered protectionTue 23 Jun 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point Cloud Firewall | Securing all of your clouds: Art of the possibleThu 25 Jun 2026 @ 10:00 AM (PDT)
AI Security Masters E10: READY OR NOT: Securing the AI Enterprise 2/5 - AI Red TeamingAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY