Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    1.2.3-RC3 extreme number of inetd processes

    Scheduled Pinned Locked Moved 1.2.3-PRERELEASE-TESTING snapshots - RETIRED
    5 Posts 3 Posters 4.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      anescient
      last edited by

      I'm running the nanobsd 1.2.3 RC3, and I noticed a huge number of processes (several hundred) on the RRD graphs.

      http://imgur.com/eZrEh.png

      http://imgur.com/fwOQZ.png

      The first drop-off is due to a reboot. The second drop-off is apparently due to an overflow at 1024(?) and an error in the graph rendering. In fact there are more than 1100 processes.

      ps aux reports an extreme number of entries like such:

      root    1683  0.0  0.1  3268  1500  ??  I    2:02AM  0:00.00 inetd: wrapping (inetd)

      I believe these are wrapping nc, but honestly I don't know that much about how these things work.

      These are being spawned in groups, and each time only a few (one?) from the previous group dies.
      For example, 5 processes launched at 2:02.
      Another 13 launched at 2:17, and 4 of the 2:02 remain.
      41 launched at 2:28, 12 of the 2:17 remain, and still 4 of the 2:02 remain.

      This seems to be caused by the Deluge bittorrent client. I started using this client after the RC3 upgrade, so I don't know if earlier versions are affected. Azureus doesn't seem to cause this problem.

      I have port forwards set up for bittorrent, and I have NAT reflection enabled.

      1 Reply Last reply Reply Quote 0
      • A
        anescient
        last edited by

        Further information:

        Disabling DHT in Deluge alleviates the problem. So the blame falls on DHT in libtorrent-rasterbar2, version 0.14.2-2ubuntu1

        1 Reply Last reply Reply Quote 0
        • jimpJ
          jimp Rebel Alliance Developer Netgate
          last edited by

          NAT reflection is what gets launched from inetd.

          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

          Need help fast? Netgate Global Support!

          Do not Chat/PM for help!

          1 Reply Last reply Reply Quote 0
          • A
            anescient
            last edited by

            I just realized that I didn't make this clear in the original post: these processes never die. Closing the offending application only stops the creation of new processes. I have to reboot pfSense to restore sanity. I assume I could kill them from the console, but I haven't tried that as I don't know how to do it without killing useful well-behaved instances and potentially breaking something.

            1 Reply Last reply Reply Quote 0
            • W
              wago
              last edited by

              I'm seeing the same thing, but without any bittorrent traffic. In my case, I think it might be UDP DNS reflection that triggers it. I'm running off CF card w/o any swap, and am getting a lot of process kills due to lack of swap (even with 512M RAM and low load), so I'm going to try rebuilding with swap space to see if this problem still exists.

              example line in /var/etc/inetd.conf

              19111 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.16 53

              example inetd process

              root  15877  0.0  0.0  3268    8  ??  IN    9:59AM  0:00.00 inetd: wrapping (inetd)

              example nc process (also hanging)

              nobody 13983  0.0  0.0  3184    8  ??  Ss    9:56AM  0:00.00 nc -u -w 2000 192.168.1.16 53

              lots of these in dmesg

              pid 15741 (inetd), uid 0, was killed: out of swap space
              pid 16286 (sh), uid 0, was killed: out of swap space
              pid 16287 (sh), uid 0, was killed: out of swap space
              […]

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.