mssql-cli
mssql-cli copied to clipboard
dbcli
man tmp files (pipe files) created and not deleted
I am running mssql-cli in a bash script in ubuntu and see hundreds of /tmp/foo files left lying around where foo is like clr-debug-pipe-29415-136842019-out clr-debug-pipe-29415-136842019-in
They are FIFO pipes I think, created by CLR.
Thanks for reporting this. Can you try setting the following environment variable, and seeing if that prevents the temp files from being created?
export COMPlus_EnableDiagnostics=0
If that works, we can roll that into the mssql-cli bootstrap/startup as a permanent fix.
I can confirm that COMPlus_EnableDiagnostics=0 works preventing clr-debug-pipe files of being created, but it does not prevent *.tmp files. It actually triggered and incident today (full usage of tmp partition) because of these *.tmp files. Is there anyway of preventing these as well?
Second this. I'm pulling hundreds of gigs onto a mounted drive on centos, yet our root drive was filling up. Found the clr* files (not taking up much space) along with dozens of *.tmp files that was up to 45G.
@sethcenterbar I actually had to come up with a cron job to remove all tmp files but the most recent, which might be still being written.
Certainly not an ideal scenario. I'm assuming this is just a problem on linux?
On Thu, Jul 30, 2020 at 11:55 AM Bruno Oliveira [email protected] wrote:
@sethcenterbar https://github.com/sethcenterbar I actually had to come up with a cron job to remove all tmp files but the most recent, which might be still being written.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dbcli/mssql-cli/issues/460#issuecomment-666483458, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB54DXU4NSBGEE4DZODF64TR6GJXRANCNFSM4MNXAJNQ .
Got bit by this too, after a quick investigation with strace I found that these pesky tmp files are created by MicrosoftSqlToolsServiceLayer. I see a lot of open("tmpXXXXXX.tmp") with corresponding close and unlink. But unlink is sometimes missing (while close is present), which cause our problem here.
This is on Linux, of course. I do not have the dotnet skills to debug further. Maybe simply bump to a newer version would be enough ?
