- Products
- Learn
- Local User Groups
- Partners
- More
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Improve Your Security Posture with
Threat Prevention and Policy Insights
Overlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
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 |
|---|---|
| 15 | |
| 8 | |
| 8 | |
| 8 | |
| 8 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 3 |
Wed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY