# /usr/sbin/lsof required by testOpenFiles unit test

XMLWordPrintable

#### Details

• Type: Story
• Status: Invalid
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:

#### Description

Unit test testOpenFiles.py failed on my Ubuntu 14.04 system. The subroutine getOpenFiles required /usr/sbin/lsof, which was not on my system. There was a /usr/bin/lsof, so I was able to get the unit test to work by adding a soft link.

#### Activity

Hide
Tim Jenness added a comment - - edited

Thanks for the report. Turns out that the getOpenFiles function in that test was not being called until we decided to "fix" the test to take open files into account. The code had been added in 2013 by Paul Price but was there for debugging purposes rather than as part of the test. Now that we are using it we are realizing that lsof is not always in the same place.

I think the real fix is to rewrite getOpenFiles to use psutil as was done in the utils package as part of DM-5561.

 def _get_open_files():  """Return a set containing the list of open files."""  return set(p.path for p in psutil.Process().open_files()) 

Show
Tim Jenness added a comment - - edited Thanks for the report. Turns out that the getOpenFiles function in that test was not being called until we decided to "fix" the test to take open files into account. The code had been added in 2013 by Paul Price but was there for debugging purposes rather than as part of the test. Now that we are using it we are realizing that lsof is not always in the same place. I think the real fix is to rewrite getOpenFiles to use psutil as was done in the utils package as part of DM-5561 . def _get_open_files(): """Return a set containing the list of open files.""" return set (p.path for p in psutil.Process().open_files())
Hide
Kian-Tat Lim added a comment -

It's not clear to me that this test should exist in the first place as opposed to running the entire stack on a limited-resource platform instance, if that is a requirement.

Show
Kian-Tat Lim added a comment - It's not clear to me that this test should exist in the first place as opposed to running the entire stack on a limited-resource platform instance, if that is a requirement.
Hide
Tim Jenness added a comment -

This test arrived as part of trac ticket https://dev.lsstcorp.org/trac/ticket/2292

Show
Tim Jenness added a comment - This test arrived as part of trac ticket https://dev.lsstcorp.org/trac/ticket/2292
Hide
John Parejko added a comment -

I've been told to take care of this one.

Show
John Parejko added a comment - I've been told to take care of this one.
Hide
John Parejko added a comment -

KT or Perry, can you please review this? I'm not opposed to just deleting it, but if we keep it it might as well work.

Show
John Parejko added a comment - KT or Perry, can you please review this? I'm not opposed to just deleting it, but if we keep it it might as well work.
Hide
John Parejko added a comment -

Marking as Invalid, as I've deleted the offending test with Kian-Tat Lim's blessing.

The test was checking behavior of astrometry.net (so it should really be part of the a.net test suite, if there is one), it often misbehaved (I'd get failures if I ran with py.test -s and successes without the "-s"), and "failure" consisted of either segfaulting (so no test reports came out at all) or a long, verbose INTERNAL ERROR that told one nothing about how to fix it.

Show
John Parejko added a comment - Marking as Invalid, as I've deleted the offending test with Kian-Tat Lim 's blessing. The test was checking behavior of astrometry.net (so it should really be part of the a.net test suite, if there is one), it often misbehaved (I'd get failures if I ran with py.test -s and successes without the "-s"), and "failure" consisted of either segfaulting (so no test reports came out at all) or a long, verbose INTERNAL ERROR that told one nothing about how to fix it.

#### People

Assignee:
John Parejko
Reporter:
Perry Gee
Reviewers:
Kian-Tat Lim, Perry Gee
Watchers:
John Parejko, Kian-Tat Lim, Perry Gee, Russell Owen, Tim Jenness