Hello, I just upgraded from community edition 3.2.2 to 3.3.2 and now discoveries do not work.  I even tried deleting one and recreating it, but nothing happens.  It shows status as "running" but no processes change on the server, nothing is generated in any log files, nothing happens.

For now, I've reverted back to my snapshot from before the upgrade.  Does anyone have any ideas for what I can look at?

    CommentAdd your comment...

    3 answers


      Hi Jason,

      You're not running with HTTPS only by chance?

      HTTP must  be enabled from localhost/ This isn't a security issue as localhost traffic never hits an actual interface and therefore isn't prone to sniffing.

      Mark U.

      1. Jason

        Good question. I think we did modify apache to redirect http to https as we do this for most configurations.  I'll look into that

      2. Jason

        That was the issue.  Good call!

      CommentAdd your comment...

      So a follow up, it appears the discoveries, while started, have frozen.  I have 75,037 items in the queue table in my database, however it has been "stuck" not doing anything for over a day.  I tried rebooting but it is not doing anything still.  How do I clear this out gracefully?  Trying to start a new discovery just adds it into the end of the queue...

      Even while it was running, this new discovery process seems slower than the prior method.

      1. Mark Unwin


        To delete the queue items, run the below.

        mysql -u openaudit -popenauditpassword openaudit -e "DELETE from queue;"

        Are you running Open-AudIT on Windows or Linux?

        Are you running the Discoveries from Community or Pro/Enterprise?

        What size is your discovery (a /24, etc)?

        The new process is an order of magnitude faster than the old. It runs truly parallel and you can increase or decrease the number of concurrently running processes.

        After you clear the queue, try running the discovery again. If it fails to execute the queue (it may take a minute to start), call the below URL.


        This may hang your browser, so I'd suggest running it in an incognito window that won't affect your existing session. You should then be able to switch back to the original window, view the Discovery and see log entries being added.


      2. Jason

        Hi Mark,

        I'm running community edition on Centos 7.7 and trying to discover multiple subnets of various sizes.

        I cleared the queue following your directions.

        I tried starting the discovery of a /22 again and nothing is being generated into the logs, nor do I see any change in cpu/memory utilization.  I tried navigating to the URL and it is just a blank page.  Running curl against the URL gives this:

        > GET /open-audit/index.php/util/queue HTTP/1.1
        > User-Agent: curl/7.29.0
        > Accept: */*
        < HTTP/1.1 200 OK
        < Date: Mon, 18 May 2020 01:34:18 GMT
        < Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
        < X-Powered-By: PHP/5.4.16
        < Content-Length: 0
        < Content-Type: text/html; charset=UTF-8
        * Connection #0 to host XXXXXXXXXXXXXXXXXX left intact

        What is really odd is that the Discovery "Started On" and "Completed On" dates are 2020-05-17 20:32:37 and 2020-05-17 20:32:38 respectively. 

      3. Mark Unwin


        The cURL or browser request should basically return nothing, so your response is expected.

        Discovery Started On and Completed On look normal. When we execute a discovery, we reset the Completed on to be after the started on. It will update itself when the discovery actually completes.

        Nothing in the response is a worry. Started On and Completed On are being editied, so it looks like at least the initial request is working.

        I'd take a look at the Apache error log at /var/log/httpd/error.log (a common place).

        Check the logs at menu → Admin → Logs ( → System Logs in Community). If there has been a failure it should show there.

        If you find nothing there, I'd set the configuration item "log_level" to 7, then re-run the discovery. Immediately after, set it back to 5. Then check the logs (menu → Admin → Logs). If you're using Enterprise or Professional the logs are nicely grouped by request and make it easy to see what happened. If you're using Community, you'll have to work through them manually.

      4. Jason

        No matter what I did, nothing would be generated in the debug logs about discoveries other than accessing/viewing the pages for them.

        I instead deleted all my discoveries and re-imported from csv.  I've started one and it is now working.  I'll see if it freezes up again.

        One possible bug I found is that when I export my discovery list in this version,  I get many lines of errors in the file above the actual lines of the discoveries that consist of

        "<div style=""border:1px solid #990000;padding-left:20px;margin:0 0 10px 0;"">",,,,,,,,,,,,,,,,,,,,,,,,,,,


        <h4>A PHP Error was encountered</h4>,,,,,,,,,,,,,,,,,,,,,,,,,,,


        <p>Severity: 4096</p>,,,,,,,,,,,,,,,,,,,,,,,,,,,

        <p>Message: Object of class stdClass could not be converted to string</p>,,,,,,,,,,,,,,,,,,,,,,,,,,,

        <p>Filename: helpers/output_helper.php</p>,,,,,,,,,,,,,,,,,,,,,,,,,,,

        <p>Line Number: 418</p>,,,,,,,,,,,,,,,,,,,,,,,,,,,


      5. Jason

        90 minutes later and the discovery is still status "running."

        The subnet I'm scanning is

        The scan started at 8:45AM CDT and the last line in the logs for the scan is at 9:07AM CDT

        2020-05-18 09:07:122865888610.84.7.255device completeIP Audit finish on device
        Command: Peak Memory
        Output: 82.954 MiB

        I'm unsure why it is scanning the broadcast address...  It also says further up in the logs that the broadcast address is responding, which seem suspect.

        2020-05-18 08:45:112861472610.84.7.255notice

        IP responding, adding to device list.

        I cannot ping it, nor does any port respond...

        I see this at the beginning of the scan, which seems odd

        2020-05-18 08:45:0828613644127.0.0.1noticeRetrieving IP list
        Command: nmap -n -sL
        Output: Total IPs: 1024
        2020-05-18 08:45:0828613645127.0.0.1noticePing response not required, assuming all 1024 IP addresses are up.
        2020-05-18 08:45:0828613646127.0.0.1noticeTesting for responding IPs
        Command: nmap -n -sL
        Output: Responding IPs: 1024
        2020-05-18 08:45:0828613647127.0.0.1noticeNmap response scanning completed.

        Shouldn't the test for responding IPs use -sn rather than -sL?

      6. Mark Unwin


        The exported discoveries issue has (now) been filed as a bug. This will be fixed for our next release. I will supply a patch if possible once it's sorted.

        Scanning the broadcast address is an Nmap thing. We supply it the subnet and it discovers the IPs. You could use an IP range instead if you deliberately want to avoid scanning that particular IP.

        The last Nmap scan using -sL is intended as you have specified that a ping response is not required. That's in the discovery scan options (configurable in Enterprise). If you're using Community, you'll need to change the global discovery_default_scan_option in the configuration to another that doesn't use that option. I always use Ultra Fast unless I have difficult devices on given IPs.


        Are devices now being discovered?

      7. Jason

        The discovery is still in status "running"

        The setting is at ultrafast for all these discoveries and the default is ultrafast

        The last log entry is still from over 24 hours ago.

      8. Mark Unwin


        Can you email the discovery support (see Open-AudIT Support Information) to marku@opmantek.com

        I'll give it a look.


      9. Jason

        Hi.  Unfortunately, I had to revert to the 3.2.2 snapshot as we needed to get it working again.  I'll be sure to upgrade again in the future, see if I can replicate the issue, and try the discovery support option if it works in community edition.

      CommentAdd your comment...

      Hello Jason,

      Thank you for posting this inquiry. We have heard similar problems from other users, and are looking into this as high-priority.

      Could you help us with a bit of testing? What version did you upgrade FROM, and what OS is this installed ON.


      Mark H

      1. Jason

        Hello, as already mentioned, I upgraded from 3.2.2

        This is running on Centos 7.7

      CommentAdd your comment...