Delete testOpenFiles #44
Conversation
| nameList = [name[1:] for desc, name in procs if desc[0] == 'f' and desc[1:].isdigit()] | ||
| return nameList | ||
|
|
||
|
|
||
| def printOpenFiles(): |
There was a problem hiding this comment.
Do we need this function at all? It's not called.
There was a problem hiding this comment.
It's called in commented out blocks. I'll delete it and those.
testOpenFiles was checking astrometry.net behavior under small file handle limits, but it usually "fails" by either segfaulting or erroring out in a way that lmakes it impossible to debug what happened. Since it's an astrometry.net problem, we should leave testing it to them.
parejkoj
force-pushed
the
tickets/DM-7661
branch
from
fe1fbf0
to
f0a33d0
Compare
|
The commit message says "Since it's an astrometry.net problem, we should leave testing it to them." That's not true --- the problem was in our use of astrometry.net. |
|
@PaulPrice Oh, interesting. That was not clear from the comments or other discussion. Do you think a test like this should continue to exist, and if so how should we make it useful e.g. actually report something helpful on failure, instead of segfaulting? |
|
I think this is an important test because it caught our wrong use of astrometry.net (we weren't closing files; I think there was also a problem in astrometry.net). I wouldn't have thought that a test failing with a segfault was not "useful". It may not give additional information, but surely the fact that it fails catastrophically is useful information. We may be moving to different catalog formats, but we still support astrometry.net and most of our existing catalogs are in that format, so this test keeps our astrometry.net reading working. |
lsof doesn't exist in the same place on all systems, so I've converted to psutil which we use elsewhere.
I had to up the limit to current+10 because it was failing on my system with 5, so apparently psutil and lsof behave slightly differently?