Skip to content
Snippets Groups Projects
New look: Off

arm doesn't consistently list connections on OpenBSD 5.1

    • Closed Issue created by Trac @tracbot

    using 1.4.5.0 tarball will sometimes work, but it eventually hangs.

    using 26ea3b0e690bbbfaf992be19829ac2fa65fc0cc7, but it hangs before drawing anything. the log seems to indicate that it hangs while calling lsof.

    going with the theme of calling external programs for information, i think an appropriate solution is to use the fstat(1) program instead of lsof(1), which is available in the base distribution of OpenBSD, FreeBSD, and NetBSD.

    Trac:
    Username: mischief

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Trac added FreeBSD OpenBSD arm component::archived/nyx owner::atagar priority::medium reporter::mischief resolution::duplicate status::closed type::defect labels

      added FreeBSD OpenBSD arm component::archived/nyx owner::atagar priority::medium reporter::mischief resolution::duplicate status::closed type::defect labels

    • Trac
      Trac @tracbot ·
      Author

      Trac:
      Username: mischief

      YCVf

    • Trac
      Trac @tracbot ·
      Author

      arm --debug log

      Trac:
      Username: mischief

    • A
      Damian Johnson @atagar ·

      Hi mischief. Is this debug log from an occurrence where arm froze? The log gets up until the point of determining that lsof was the only resolver worth trying on your system, then nothing.

      If this was the point of the freeze then please try running the following...

      lsof -wnPi | egrep "^tor *<tor_pid>.*((UDP.*)|(\(ESTABLISHED\)))"

      ... filling in the '<tor_pid>', of course. ;)

      As I see it there's two issues here...

      • Arm's hanging. This should never happen, so this is what I'm interested in fixing.

      • Arm doesn't show the connections on OpenBSD, and could use fstat to do so. I'm happy to merge a patch for this and help if you have questions, but I don't plan to write this myself. It would be tricky for me to do since I don't have a system to develop it against (and before you offer one, I've tried developing against OpenBSD before - I couldn't even get vim to work properly on the accursed thing).

      Cheers! -Damian

      Trac:
      Status: new to needs_information

    • A
      Damian Johnson @atagar · 
      14:04 < mischief> atagar: this is the output of fstat -p <torpid>:  http://sprunge.us/cGXa

USER     CMD          PID   FD MOUNT        INUM MODE       R/W    SZ|DV
_tor     tor         4667 text /usr/local   186027 -r-xr-xr-x   r  1250488
_tor     tor         4667   wd /var        30774 drwx------   r      512
_tor     tor         4667    0 /            1485 crw-rw-rw-  rw     null
_tor     tor         4667    1 /            1485 crw-rw-rw-  rw     null
_tor     tor         4667    2 /            1485 crw-rw-rw-  rw     null
_tor     tor         4667    3 pipe 0xfffffe8016b1bb48 state: 
_tor     tor         4667    4 pipe 0xfffffe8016b1bb48 state: 
_tor     tor         4667    5 kqueue 0xfffffe801ca4f700 0 state: S
_tor     tor         4667    9* internet stream tcp 0xfffffe800bf88500 127.0.0.1:9051
_tor     tor         4667   10* unix dgram 0xffff8000007a3100 <-> 0xffff8000003cf100
_tor     tor         4667   11 /var        30775 -rw-------  rw        0
_tor     tor         4667   12* internet dgram udp 199.102.76.134:47400 <-> 208.79.80.18:53
_tor     tor         4667   13* internet dgram udp 199.102.76.134:37470 <-> 208.79.80.244:53
_tor     tor         4667   15* internet stream tcp 0xfffffe800d1b58f0 199.102.76.134:39903 --> 212.112.245.170:443
_tor     tor         4667   16* unix stream 0xffff80000063bb00 <-> 0xffff8000007bd480
_tor     tor         4667   17* unix stream 0xffff8000007bd480 <-> 0xffff80000063bb00
_tor     tor         4667   61* internet stream tcp 0xfffffe801de0e8d8 127.0.0.1:9051 <-- 127.0.0.1:17957

      Trac:
      Status: needs_information to assigned

    • A
      Damian Johnson @atagar ·

      Hopefully we'll add OpenBSD connection support in #7910 (closed).

    • F
      fk @fk ·

      Replying to mischief:

      going with the theme of calling external programs for information, i think an appropriate solution is to use the fstat(1) program instead of lsof(1), which is available in the base distribution of OpenBSD, FreeBSD, and NetBSD.

      I don't think fstat is appropriate for FreeBSD as it doesn't show the connection details:

      USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W
_tor     tor         2567 text /usr/jails/tor-jail   4276 -r-xr-xr-x  14677809  r
_tor     tor         2567   wd /usr/jails/tor-jail   3715 drwx------      13  r
_tor     tor         2567 root /usr/jails/tor-jail      3 drwxr-xr-x      21  r
_tor     tor         2567 jail /usr/jails/tor-jail      3 drwxr-xr-x      21  r
_tor     tor         2567    0 /usr/jails/tor-jail/dev     25 crw-rw-rw-    null rw
_tor     tor         2567    1 /usr/jails/tor-jail/dev     25 crw-rw-rw-    null rw
_tor     tor         2567    2 /usr/jails/tor-jail/dev     25 crw-rw-rw-    null rw
_tor     tor         2567    3
_tor     tor         2567    4* internet stream tcp fffffe0077706000
_tor     tor         2567    5* internet stream tcp fffffe007504a000
_tor     tor         2567    6* internet dgram udp fffffe0017ad3188
_tor     tor         2567    7* internet stream tcp fffffe007505bb70
_tor     tor         2567    8* internet stream tcp fffffe007505b7a0
_tor     tor         2567    9* local stream fffffe0017b00c30
_tor     tor         2567   10 /usr/jails/tor-jail/dev     65 crw-rw----      pf rw
_tor     tor         2567   11 /usr/jails/tor-jail    862 -rw-r-----   24076  w
_tor     tor         2567   12 /usr/jails/tor-jail    863 -rw-r-----  12951160  w
_tor     tor         2567   13 /usr/jails/tor-jail/dev     25 crw-rw-rw-    null  w
_tor     tor         2567   14 -          3721 -rw-------       0 rw
_tor     tor         2567   15* internet stream tcp fffffe0077a94b70

      Apparently it also gets the working directory wrong, and by the way it looks questionable in the OpenBSD example given above as well.

      "Arm hanging" is a problem I reported before in the past and I don't think it has anything to do with lsof. I've locally patched stem to use procstat instead of lsof (for other reasons) and it didn't make a difference.

      My impression is that only the GUI becomes unresponsive, control port traffic is still logged. It could be related to redraws, but I haven't recently looked at it.

      It would probably help debugging if arm would catch SIGHUP to "reboot the GUI" after logging the current state.

    • F
      fk @fk ·

      Replying to fk:

      My impression is that only the GUI becomes unresponsive, control port traffic is still logged. It could be related to redraws, but I haven't recently looked at it.

      While trying to debug this I noticed that increasing the debug level made the problem worse and that adding unconditional log messages in LogPanel.draw() causes the GUI to reproducibly lock up after a couple of draw() calls.

      Thus I tried the attached patch which removes the two conditional log messages and haven't seen any lock ups since.

      I'm not suggesting that this is the real fix, but it certainly seems to help in my case.

      Trac:
      Keywords: N/A deleted, FreeBSD added

    • F
      fk @fk ·

      Trac:
      arm-1.4.6_dev-0001-Remove-log-messages-in-LogPanel.draw.patch

    • A
      Damian Johnson @atagar ·

      Hi fk. We just got another ticket about OpenBSD connection resolution support. Resolving this in favor of it since adding fstat support to Stem is the right way forward...

      https://trac.torproject.org/projects/tor/ticket/13807

      Trac:
      Resolution: N/A to duplicate
      Status: assigned to closed

    • Trac closed

      closed

    • Damian Johnson mentioned in issue #7910 (closed)

      mentioned in issue #7910 (closed)

    Please register or sign in to reply