Littering in /tmp on R82 MDS

[Hugo_vd_Kooij]

We found some Littering on R82 MDS machines.

It seems the /tmp directory is used but not cleaned up properly.

You can find the stuff with the following command:

find /tmp -name 'bladesStatus*' -exec ls -ld {} \;

And if neded you can cleanup with:

find /tmp -mtime +30 -name 'bladesStatus*' -exec rm -r {} \;

Which only leaves you with the last 30 days of this stuff.

But it would be nice if a system is a bit more tidier and cleans up after itself.

Is seems like something runs at a 6 hours interval but failed to cleanup this bit.

Anyone else seen this?

[the_rock]

Is there possibly a cron job there there?

[Hugo_vd_Kooij]

We use plenty of crontab jobs. But none of them every 6 hours. ... But the default update check is every 6 hours .... So that might be where this happens.

Did anyone see it on normal SmartCenters? I don't have access to one at the moment that runs R82.

[Hugo_vd_Kooij]

I just checked and my R82.10 MDS doesn't create them.

[Expert@MDS01:0]# find /tmp -name 'bladesStatus*' -exec ls -ld {} \;
drwxr-xr-x 2 admin config 47 Feb 16 17:24 /tmp/bladesStatus
[Expert@MDS01:0]#

[the_rock]

From my R82 lab:

[Expert@CP-MANAGEMENT:0]# find /tmp -name 'bladesStatus*' -exec ls -ld {} \;
drwxr-xr-x 2 admin config 100 Apr 20 2025 /tmp/bladesStatus
[Expert@CP-MANAGEMENT:0]#

[the_rock]

I have R82 lab mgmt, never seen that issue.

[Hugo_vd_Kooij]

The odd thing is we got a incident from a customer about the root partition filling up.  That's when I started to investigate our R82 MDS farm. And it happens on all of them. Not on R81.20 neither on R82.10 and I guess it didn't happen on older versions as well.

I'll see if I can update with a `screenshot` of it. And there is now a TAC case for it.

[the_rock]

Sounds good, keep us posted!

[Hugo_vd_Kooij]

Oh. I spotted this also on on our last R81.20 MDS machines as well. They are rapidly going extinct as we upgrade them to R82.

TAC is investigating.

[Vincent_Bacher]

Interesting point. On my R82.10, I can't see any 'bladeStatus*' directories, but on our production MDS, I can see more than 400 of them, each consuming 8 KB.
I will check if we want to implement a cron job for that. Thanks for notifying.

[Vincent_Bacher]

We did not impement a cron but asked our designated diamond service engineer to take care about it.

[Hugo_vd_Kooij]

The current TAC solution on the table is a slight modification of the enabled_blades.sh script.

But the suggest solution to remove the $TMP directory this script creates should allready be in the script and be triggerd by a trap line:

#deletes the temp directory
function cleanup() {
rm -rf $TMP
exit 0
}
## Trap cleanup function on exit or signa
trap cleanup SIGHUP SIGINT SIGQUIT SIGABRT SIGKILL SIGSEGV SIGTERM

---

This trap line is missing the EXIT condition. So either the function should be called upon at the end of the script explicitly or the script should add the EXT condition to the trap.

In it's present form if you call upon the script enabled_blades.sh on a MDS the script will create a temp directory and not clean it. 

I have tested this as temp solution based upon the suggestion from Check Point TAC and the diff to the script is below:

# diff -u /opt/CPshrd-R82/bin/enabled_blades.sh.20260401 /opt/CPshrd-R82/bin/enabled_blades.sh
--- /opt/CPshrd-R82/bin/enabled_blades.sh.20260401 2026-04-01 14:03:52.991495041 +0200
+++ /opt/CPshrd-R82/bin/enabled_blades.sh 2026-04-01 14:08:11.761820408 +0200
@@ -11,11 +11,14 @@

#deletes the temp directory
function cleanup() {
- rm -rf $TMP
+ if [[ $TMP == /tmp/* ]]; then
+ echo "Cleanup $TMP"
+ rm -rf $TMP
+ fi
exit 0
}
# Trap cleanup function on exit or signal
-trap cleanup SIGHUP SIGINT SIGQUIT SIGABRT SIGKILL SIGSEGV SIGTERM
+trap cleanup EXIT SIGHUP SIGINT SIGQUIT SIGABRT SIGKILL SIGSEGV SIGTERM

# blades - format is: "short name for user" property-name [inner set-name]
cat<<_ > $TMP/blade_names

You can remove the echo command once you done testing this as a possible solution.

And manualy remove the temp stuff with:

rm -rf /tmp/bladesStatus.*

[Hugo_vd_Kooij]

AI pointed out that I should use 

trap cleanup EXIT INT TERM

And it made some compeling arguments for avoiding the long list above.

[Hugo_vd_Kooij]

As it stands this isue is still present in the latest jumbo hotfix on R82.

So any fix you do manualy will be gone at the next patch stop untill Check Point reviews the code and fixes the error.

It's a simple fix with a simple solution. So why was it missed in several Jumbo Hotfixes?