Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-7661

/usr/sbin/lsof required by testOpenFiles unit test

    XMLWordPrintable

    Details

      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.

        Attachments

          Issue Links

            Activity

            Hide
            tjenness 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
            tjenness 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
            ktl 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
            ktl 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
            tjenness Tim Jenness added a comment -

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

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

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

            Show
            Parejkoj John Parejko added a comment - I've been told to take care of this one.
            Hide
            Parejkoj 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
            Parejkoj 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
            Parejkoj 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
            Parejkoj 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:
              Parejkoj John Parejko
              Reporter:
              pgee Perry Gee
              Reviewers:
              Kian-Tat Lim, Perry Gee
              Watchers:
              John Parejko, Kian-Tat Lim, Perry Gee, Russell Owen, Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins Builds

                  No builds found.