This should not be a problem because cron jobs are executed in their own processes (not threads) and they should just die. Anyway, I cannot completely exclude it either.
On Jul 6, 6:32 pm, ron_m <ron.mco...@gmail.com> wrote: > Maybe one possibility is if your code has classes with a __del__ method in > them, Massimo would have better perspective on if this is a possibility. If > a class with this method is involved in a circular reference the garbage > collector cannot clean it up because of uncertainty of execution of the > __del__ method. This was discussed a lot on the group a few months back. I > believe exec also has to be involved. Do a search for __del__ in the group > to see what was said. There were also some tools mentioned in those threads > that help with tracking down this sort of problem. > > I find in Python as soon as a file variable binding produced by open goes > out of scope it is closed, you don't have to specifically call close on it. > Normally objects are dropped as soon as the reference count reaches 0. The > garbage collector was added to clean up the circular referenced objects that > will never get a count down to 0 without some outside help. It searches the > heap looking for objects that have no references except other objects also > in the garbage and marks those as candidates to clean out. The fact that > these file objects are piling up means something is holding the file > reference which also cannot be cleaned up. > > Are you running on Linux? If so the /proc/pid_of_web2py/fd directory using > ls -l will show you what files by name are open to the process which might > provide some clues to which part of your code.
