• Resolved chrism82

    (@chrism82)


    We have a site where the Wordfence scan is repeatedly failing. There are no errors shown in the web server log files and i’ve tried all of the troubleshooting steps in the Wordfence documentation.

    I’ve enabled debugging mode and run a scan and these are the last few lines before the scan fails:

    [Jun 24 13:36:55:1624531015.875584:4:info] Scan process ended after forking.
    [Jun 24 13:36:50:1624531010.861870:4:info] Starting cron with normal ajax at URL https://domain.com/wp-admin/admin-ajax.php?action=wordfence_doScan&isFork=1&scanMode=standard&cronKey=cf14d76cc41eb2f6fbf555db9622cc41&signature=bbd7bcebe464f71c20f0eddc3737f7697ab381f1721d886b9c7bb588385ed716
    [Jun 24 13:36:50:1624531010.859155:4:info] Test result of scan start URL fetch: array ( 'headers' => Requests_Utility_CaseInsensitiveDictionary::__set_state(array( 'data' => array ( 'date' => 'Thu, 24 Jun 2021 10:36:50 GMT', 'content-type' => 'text/html; charset=UTF-8', 'x-powered-by' => 'PHP/7.4.13', 'x-robots-tag' => 'noindex', 'x-content-type-options' => 'nosniff', 'expires' => 'Wed, 11 Jan 1984 05:00:00 GMT', 'cache-control' => 'no-cache, must-revalidate, max-age=0', 'x-frame-options' => 'SAMEORIGIN', 'referrer-policy' => 'strict-origin-when-cross-origin', 'cf-cache-status' => 'DYNAMIC', 'cf-request-id' => '0adf311bec0000000a23061000000001', 'expect-ct' => 'max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"', 'report-to' => '{"endpoints":[{"url":"https:\\/\\/a.nel.cloudflare.com\\/report\\/v2?s=M2yMLpnDvpzl1Y2OHCkYVPsVrlGTHlpTD3IK8nZHEyiyz7bkIDRnPAFHViXt%2BD28ePaqjzO3gEsLP0og5%2FqAWPg5eLUrZfoYnQd
    [Jun 24 13:36:50:1624531010.415956:4:info] getMaxExecutionTime() returning config value: 20
    [Jun 24 13:36:50:1624531010.415279:4:info] Got value from wf config maxExecutionTime: 20
    [Jun 24 13:36:50:1624531010.414383:4:info] Calling startScan(true)
    [Jun 24 13:36:50:1624531010.100319:4:info] Entered fork()
    [Jun 24 13:36:50:1624531010.099405:4:info] Calling fork() from wordfenceHash with maxExecTime: 20
    [Jun 24 13:36:49:1624531009.991691:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/attendee-collection/iac-setting/__tests__/__snapshots__/template.test.js.snap (Mem:76.0M)
    [Jun 24 13:36:49:1624531009.921491:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/attendee-collection/container.js (Mem:76.0M)
    [Jun 24 13:36:49:1624531009.917290:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/advanced-options/template.js (Mem:76.0M)
    [Jun 24 13:36:49:1624531009.815073:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/advanced-options/style.pcss (Mem:76.0M)
    [Jun 24 13:36:49:1624531009.796768:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/advanced-options/sku/template.js (Mem:76.0M)
    [Jun 24 13:36:49:1624531009.791959:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/advanced-options/sku/container.js (Mem:76.0M)
    [Jun 24 13:36:49:1624531009.785262:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/advanced-options/sku/__tests__/template.test.js (Mem:76.0M)
    [Jun 24 13:36:49:1624531009.600350:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/advanced-options/sku/__tests__/__snapshots__/template.test.js.snap (Mem:76.0M)
    [Jun 24 13:36:49:1624531009.540255:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/advanced-options/move-delete/template.js (Mem:76.0M)
    [Jun 24 13:36:49:1624531009.535631:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/advanced-options/move-delete/style.pcss (Mem:76.0M)
    [Jun 24 13:36:49:1624531009.452471:4:info] Scanning: /var/www/html/wp-content/plugins/event-tickets/src/modules/blocks/ticket/container-content/advanced-options/move-delete/container.js (Mem:76.0M)

    The site is running Wordfence 7.5.4 on WordPress 5.7.2.

    Can anyone suggest what we can do to fix this?

    Thanks,
    Chris

Viewing 7 replies - 1 through 7 (of 7 total)
  • Does your server have sufficient memory to run the scan?

    Plugin Support wfpeter

    (@wfpeter)

    Hi @chrism82, thanks for dropping us a detailed message with your scan results.

    Please check the instructions under Scan process ended after forking in our documentation to ensure permissions and .htaccess blocks are not preventing access to the wp-admin folder. Memcache or object-cache may also need to be restarted twice if present on your configuration. Also ensure your own server IP has access to this folder. It seems that “Maximum execution time for each scan stage” is already set to our recommended value of 20 to help prevent timeouts.

    If you have no luck there, could you send a diagnostic report to wftest @ wordfence . com? You can find the link to do so at the top of the Wordfence Tools > Diagnostics page. Then click on “Send Report by Email”. Please add your forum username where indicated and respond here after you have sent it.

    Note: For the fastest response time, please make sure and add any information or questions directly to this topic and not the email address above unless asked.

    Thanks,

    Peter.

    Thread Starter chrism82

    (@chrism82)

    Hi Peter,

    Thanks for your reply.

    I have checked file permissions as per the link you sent and all is good there. The scan continues to fail after 2000-8000 scanned files (8000 is the most i’ve seen it achieve but it normally fails around 2000 files – there seems to be no predictable pattern for how many files it can process before it fails).

    I’ve just sent the diagnostic report as requested – can you take a look please?

    Also i’ve tried disabling PHP opcode and the scan still fails with this disabled.

    Thanks,
    Chris

    • This reply was modified 3 years, 5 months ago by chrism82.
    Plugin Support wfpeter

    (@wfpeter)

    Hi @chrism82, thanks for providing your diagnostic.

    The only main things I notice are your WordPress memory limit could be higher, and we could try a lower resource scan that increases scan times but slows things down to be less intensive all at once. There are no errors in terms of access restrictions or permissions that are fundamental to the functioning of the scans.

    1. Navigate to Wordfence > All Options
    2. Scroll to the “Performance Options” section.
    3. Check the box that says “Use low resource scanning (reduces server load by lengthening the scan duration)”.
    4. Save the change.

    If the above doesn’t stop the scans from dying part-way through, WP_MEMORY_LIMIT is set to 40MB whereas PHP’s “memory_limit” is 256MB so there’s quite a big disparity. You can edit your “wp-config.php” file either via FTP or in your hosts’ file manager to raise the WordPress memory limit.

    Add this line to the very bottom of “wp-config.php”, right before the line that says, “Happy Blogging”:

    define('WP_MEMORY_LIMIT', '128M');

    Let me know if that gives your site a bit more chance to complete a scan.

    Thanks,

    Peter.

    Thread Starter chrism82

    (@chrism82)

    Thanks @wfpeter. I just tried both of those suggestions but the scan still dies half way through. With the memory limit increased to 256MB and running in normal mode (not low resource mode) it scanned 5000/20000 files and then died. With low resource mode it scanned 2000/20000 files and then stopped.

    The site is hosted on a VPS running on CentOS 7 so we have full control over the services. It’s just strange that we don’t see any errors logged in any log files so it’s hard to pinpoint what is causing this.

    Do you have any other ideas?

    Thanks again.

    Thread Starter chrism82

    (@chrism82)

    I’ve done some further troubleshooting to try and identify which part of the scan was causing this issue for our site.

    On the “Scan Options and Scheduling” page I disabled all of the scan options and then selectively enabled them one at a time, each time running a scan to see if it succeeded or failed.

    Strangely enough all of these scan attempts were successful to the point that no scans were failing with any/all options enabled. I then switched it from Custom Scan to Standard Scan mode and the standard scan was also successful.

    I have no idea what or why this has fixed the issue but we can now run scans without them failing. In summary it seems that selectively re-enabling each scan option one at a time helped the scan to complete.

    Hopefully this information may helpful someone else in the future with the same issue.

    Plugin Support wfpeter

    (@wfpeter)

    Hi @chrism82,

    Thanks for getting back to us with the results of those further tests. Sometimes a plugin reset can re-trigger the scans, which I only see as a last resort usually but it seems that perhaps disabling some of the options had a similar effect. I’ll look into this further as a possible solution for other customers, but very pleased this has resolved for you.

    Thanks,

    Peter.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Scan Failed’ is closed to new replies.