[Wouter Camps]

Bryon,

Thx for clearing out the exact nature of the fix.
All tmp files have already been deleted, it took a while, but luckily our other isms appliance didn’t suffer from the same problem so I didn’t have to do it twice. I guess the ‘boa-session-*’ files on our problematic isms where generated under special circumstances that never occured like that on the second one.

Kind regards,
Wouter

[Wouter Camps]

Hi Bryon,

I upgraded the gateway to the latest firmware as a part of my troubleshooting, but this didn’t seem to change anything about the number of ‘boa-session-*’ files already present in ‘/usr/local/tmp’. More than a day after the upgrade to firmware version 1.51.28, more than 78 000 files were still present in the tmp directory (after I’d already done a lot of manual deleting the previous day). In the end I deleted all ‘boa-session-*’ files manually. Can you confirm that the new firmware is supposed to avoid creating those files in the first place (or cleaning them up immediately) instead of just cleaning up older files like I presumed?

Wouter

[Wouter Camps]

Hi Bryon,

Thanks for your fast response, but because of the time zone difference I guess, it took more time than I wanted to waste (with no more backup device, failure of our second gateway would mean no more alerting at all and the ‘disk space like’ problem seemed a scenario that could also happen to our only remaining device). So I did a grep on ‘ssh’ and ‘telnet’ on the exported config of our other gateway and already figured out there was an open telnet port at 2222 like you said in your post. I logged in and noticed with df -k there was no disk space problem (‘/usr/local’) was only 14% full, but even so, I wasn’t able to make a new file in /usr/local/tmp using ‘touch’. I tried to ‘rm /usr/local/tmp/*’, but I got an error message, saying ‘sh: /bin/rm: Argument list too long’. ‘ls /usr/local/tmp/*’ also took very long and resulted in a huge huge number of files. I found some patterns to rm a lot of files at once (e.g. ‘rm boa-session-V3*’). Next, I retried to log in using the web interface, and this time I got past the login screen! So in the end, the problem didn’t seem to be the disk space, but the sheer number of files.

Can you tell me what we can do to avoid this problem in the future, because as I see it, it’s just a question of time before the number of files in /usr/local/tmp grows too big again and our gateway(s) will cease to function again. Is this firmware related (we’re currently at 1.50.7) and solved in a more recent software version? Or is there a way to clean ‘/usr/local/tmp’ on a regular basis by using some function in the webinterface? It seems there should be at least some sort of cron job in the appliance deleting ‘old’ tmp files after a while.

[Author]

Posts