High load of "check_reload_status" - public Tools Repo out of Sync?



  • We have successfully build our own pfSense 2.2 ISO image. With this version we experience a high load (100% CPU) coming from the process "check_reload_status". The high load is gone, if we copy the binaries "check_reload_status", "pfSctl" and "fcgicli" from the BETA-2.2 snapshots.

    Therefore it should not be a configuration problem on our installation. It seems to be related to the pfPort "check_reload_status" from the "Tools Repo".

    Remark: Our binaries have nearly double the size of the snapshot binaries:

    [super@freebsd]$ wc -c /
    22320 snapshop-beta-2-2/check_reload_status
    11336 snapshop-beta-2-2/fcgicli
      7928 snapshop-beta-2-2/pfSctl
    48330 test-2-2/check_reload_status
    22282 test-2-2/fcgicli
    16073 test-2-2/pfSctl

    Please cross check the "check_reload_status" of the tools repo and the beta snapshots.

    Best regards



  • @thhi:

    Remark: Our binaries have nearly double the size of the snapshot binaries:

    Binaries on 2.2 snapshots are stripped, or at least they are now.  If yours are not, that would explain the size differences.

    Sorry, I haven't looked into the 2.2 build process since the licensing change, so I can't help there.



  • I have rebuild "check_reload_status" with the git commit "563c70dea12890ac0525c56557ade142d3098285" (Make check_reload_status depends of libevent2 since version was dropped and it's completely backward compatible…). The high load problem remains.

    However the lastest shapshot version (from 15-Oct) uses libevent-1.4. Perhaps the library version libevent2 isn't 100% backward compatible?

    [2.2-BETA][root@pfSense.localdomain]/root(1): ldd /usr/local/sbin/check_reload_status
    /usr/local/sbin/check_reload_status:
    libsbuf.so.6 => /lib/libsbuf.so.6 (0x800848000)
    libevent-1.4.so.4 => /usr/local/lib/libevent-1.4.so.4 (0x800a4a000)
    libc.so.7 => /lib/libc.so.7 (0x800c65000)

    I have opened a bug report on redmine:

    https://redmine.pfsense.org/issues/3940


Log in to reply