exitmap icon indicating copy to clipboard operation
exitmap copied to clipboard

/tmp/pymp-XXX directories not always cleaned up

Open NullHypothesis opened this issue 8 years ago • 3 comments

Sometimes, exitmap won't delete all temporary pymp directories in /tmp/. This might only happen in case of a non-clean shutdown. Either way, it should be fixed.

NullHypothesis avatar Mar 12 '16 18:03 NullHypothesis

Hi, I was thinking of trying to fix this and was reading more about it. I can see that src/eventhandler.py is mainly responsible for creating these directories. I will be looking at the multiprocessing python module to see how we can clean the directories in /tmp the right way. Any head start that I could use is appreciated.

What I'll try for now is understand how multiprocessing is being used in exitmap and try to add checks for unclean shutdowns and code the necessary steps needed.

PS: Found this issue that suspiciously looks similar, could be a head start.

paperbackraita avatar Apr 15 '16 09:04 paperbackraita

Thanks for looking into this!

I will be looking at the multiprocessing python module to see how we can clean the directories in /tmp the right way. Any head start that I could use is appreciated.

My only guess is that some module invocations might never terminate, which is why their working directory remains when exitmap is done.

NullHypothesis avatar Apr 15 '16 13:04 NullHypothesis

Firstly, irrespective of whether I give exitmap a clean shut down or not, the pymp-* folders and the temporary Tor directory are never deleted when I run the various modules, which is weird.

I read about multiprocessing in Python and checked eventhandler.py for some clues. I've modified the select_exits function in exitmap.py to check for only 2 exit relay fingerprints for now for testing purposes, and I hope that doesn't cause any issues.

Currently, I've understood that the module_closure function returns the actual function to be run as a new subprocess whenever a new circuit is created using the EventListener class. This process is simply started asynchronously as a daemon and then is terminated together in a batch using proc.terminate(). I suspect this could be leaving behind the directories as the exit doesn't look to be clean. Comments and suggestions here are appreciated as this is just a hunch.

I'll be trying to see if there is a cleaner and more elegant way for the modules processes calls to end from the multiprocessing module. I'll keep you posted.

paperbackraita avatar Apr 18 '16 18:04 paperbackraita