Linux kill command and temporary files

[Daniel Feenberg]

The Linux "kill -1 pid" command doesn't kill a Stata job running in background. The "kill -9 pid" command does kill the job, but leaves the temporary files. Eventually users start to get messages like "file /tmp/St14980.000003 already exists". We can delete old /tmp files, but some users run jobs for weeks on end so picking a safe age to harvest /tmp files isn't straightforward. Deleting an open file won't affect Stata but if Stata closes and tries to reopens a deleted file the job would presumably crash. Does Stata ever do that? Is there a better solution?

We are curruently running Statamp 14.2 under Linux kernel 2.6.32, but as far as I can recall, this has been the situation since forever..

daniel feenberg

[William Lisowski]

Have you tried "kill pid" or one of the other options described in the man page for kill?

[Daniel Feenberg]

Just tried that. It does kill the job, but the tmp files remain, so it mimics "-9".

[William Lisowski]

My kill man page tells me that the default option is to send the TERM signal (15), not the KILL signal (9), which cannot be caught or ignored by the signaled process. In general these codes are consistent across Unix implementations, so I'd expect my macOS codes are the same as your linux codes.

I guess it's time to try the other options described in the linux man page for the kill command (or perhaps the man page for the shell you run commands from). Perhaps your linux sysadmin could advise you.

Alternatively, you could contact Stata Technical Services and ask of them what kill signal does Stata catch and clean up before exiting. I would have expected this to be in the [GSU] Getting Started with Stata for UNIX manual, but searching the PDF for "kill" and for "break" doesn't produce anything useful.

So if you do find a solution, please post it here, and if it is Technical Services that provides an answer, please suggest to them that the answer is a candidate for inclusion in a future update to the [GSU] material on batch processing.

Also, on the macOS flavor of Unix, if I create a temp file within Stata

. tempfile gnxl

. display "`gnxl'"
/var/folders/xr/lm5ccr996k7dspxs35yqzyt80000gp/T//S_32853.000001

and then from the command line

% ps -fp 32853
  UID   PID  PPID   C STIME   TTY           TIME CMD
  502 32853     1   0 11:58AM ??         0:22.40 /Applications/Stata/StataSE.app/Contents/MacOS/StataSE

we see that the Process ID (PID) is built into the name of the temporary file, and that in my example the Stata task that created the temporary file started at 11:58AM and has been running for 22 minutes. That could help you with your attempts to clean up after killed Stata sessions, if you cannot find a way to kill them cleanly. Again, something else that any sysadmin should be able to help with.

[Mauricio Caceres]

FWIW, if you start Stata from the bash prompt/in batch mode, temporary files follow a similar pattern on Linux as the one William reports on OSX (not so for xstata). I have encountered this problem several times with killing stata and this thread gave me the idea to write a short script to delete all files in /tmp that match a given PID. I put the small script up on github as a gist, in case it's useful: https://gist.github.com/mcaceresb/e3...08891329de493f (python2; you can run "kill_clean PID -f -9"). I presume you can write something similar if you want a bash or csh script.

It's obviously not ideal, but it works.

[Daniel Feenberg]

Tech support replied with the suggestion that each user be their own tmp directory. I don't like adding to the user knowledge burden with site specific requirements like this, so we now have a cron job that deletes all Stata temp files that do not include a digit string corresponding to a running process. I think thgivenat will do. Unexplained is why Stata bothers to trap the TERM signal, if not to take the opportunity to clean up the temporary files.

[William Lisowski]

Thank you for closing the loop with this somewhat disappointing response from Stata Technical Support.

A point of clarification: Stata is likely not trapping the TERM (15) signal; it's letting the operating system do the default processing, which for TERM is to cause the process to terminate. I'm not sure if Stata is trapping the HUP (1) signal, or if the operating system default is to ignore it.

Really, Unix and its derivatives provide all those trappable termination codes with the idea that the program can trap them and exit appropriately, or not at all in some cases, so it seems a shame that Stata doesn't avail itself of this capability. Next time I stumble across the "wishlist for Stata 16" topic on Statalist, I'll add this in. At least now we know why it wasn't documented in [GSU]

The cron job you've created is not unlike SAS's cleanwork command for system administrators. However, my recollection, now a few years old, is that SAS handles different kill signals differently and the only files that need cleaning up are when SAS is killed with the KILL (9) signal which is untrappable.