Scan stuck or incomplete: server time, memory, cron limits and resuming the scan

Objective

This article explains how to diagnose and fix a Securantis scan that is stuck or incomplete. You will learn which server resources to check (PHP execution time, memory), how the batch / scheduled task mechanism (cron or workers) operates depending on the platform, and how to safely resume an interrupted scan without risking loss of reports or quarantining files without human decision.

Who this article is for

• Site administrators of WordPress / WooCommerce using the Securantis agent.
• Store administrators of PrestaShop 1.7–9 using the Securantis module.
• Hosting providers and technical teams who want to understand execution limits and resume a scan.

General principles (applicable to all platforms)

• The scanner traverses many files and checks integrity and signatures: this is a time- and I/O-intensive operation.
• Depending on the hosting, a full scan can exceed default PHP limits (max_execution_time, memory_limit), the web server limits, or the task manager (cron/worker).
• When a scan is interrupted, partial results are preserved; quarantine, restoration or deletion of detected files always require human action.

Prerequisites before any action

• Recent backup of the site and files (full copy or snapshot).
• Administrator access to the Securantis interface and to hosting (control panel, console or SSH as available).
• Verify that the Securantis license is active and that the agent / module is up to date.

Diagnostic and remediation steps — WordPress / WooCommerce

1. Check the job history and status in the Securantis interface
   • Review logs and the status of the last scan (completed, interrupted, pending). Note the stop time and any error messages.
2. Confirm the execution mode
   • Depending on your installation, the scan may run immediately (direct mode) or in incremental tasks (batch/worker). Incremental tasks use small batches to avoid timeouts.
3. Check PHP limits
   • Verify max_execution_time and memory_limit. On shared hosting these values can be low (e.g. 30 s, 128M). If possible and safe, temporarily increase them (e.g. 300 s, 512M) to run a full scan.
   • If you cannot change php.ini, prefer the incremental batch mode.
4. Check cron / workers
   • If the scanner relies on scheduled tasks, confirm that the system cron or WordPress CRON (WP-Cron) is working and that there are no recurring errors.
   • For WooCommerce, avoid running large tasks during peak hours to prevent impacting the store.
5. Start a background-compatible scan
   • Choose the “background-compatible” mode (or equivalent) in the interface: this mode sends the work in small batches to respect strict limits.
6. Monitor I/O and CPU load
   • During execution, monitor CPU and I/O usage. If there are spikes, choose an incremental scan or schedule it during off-peak hours.

Diagnostic and remediation steps — PrestaShop 1.7–9

1. Check the module interface
   • In the Securantis module, note whether the scan is started in “scan & hardening” background mode, quick mode, or direct mode. The module typically displays status messages.
2. PHP limits and workers
   • As with WordPress, check max_execution_time and memory_limit. Shared PrestaShop hosting often imposes strict limits; enable background mode if available.
3. Server scheduled tasks
   • PrestaShop should not rely on WP-Cron: use the system cron (or the task mechanism recommended by the module) to run batches.
4. Scan in background-compatible mode
   • If the module provides a background-compatible mode, enable it to avoid timeouts. This mode fragments the scan and allows automatic resumption of batches.

Expected result after remediation

• The scan resumes and progresses to 100% or until all scheduled batches have been processed.
• Alerts and reports are synchronized with the Securantis SaaS platform.
• No automatic action is taken on detected files: suspected items must be manually validated before quarantining or deletion.

Prudent settings

• Do not leave an increased memory_limit or max_execution_time permanent without security validation: increase them temporarily for the scan, then revert to safe values.
• Limit full scans to off-peak hours for production stores.
• If you enable a background mode, check the task frequency to avoid overloading the server.

Common errors and their meaning

• Scan interrupted with “timeout” or no progress: generally related to max_execution_time or a worker that dies.
• Jobs queued but not processed: cron not executed, WP-Cron disabled or insufficient permissions to run the process.
• Insufficient memory / process killed: indicates memory_limit is too low; the system may also kill the process to protect the server.
• Partial report without final results: the job was interrupted; entries already scanned are valid but the work is not complete.

Step-by-step troubleshooting

1. Reproduce the problem by opening the last job and re-running a scan in a small batch (background mode). If the problem does not occur, continue monitoring progress.
2. If the job fails quickly, enable detailed logs on the agent/module and collect the error messages.
3. Check server logs (web and PHP) for process killed events, permission errors or resource overflows.
4. Test a scan on a subset of files (e.g. themes or modules folder) to isolate problematic files.
5. If a batch is stuck on a network file (NFS, remote storage), run the scan locally or adjust I/O timeouts.

Important precautions

• Do not isolate or delete detected files without manual verification: all quarantine or deletion operations require human decision.
• Never send passwords or credentials by email or chat. If access is required for a paid intervention, it will be requested via the secure client area after payment.
• Do not assume all hosting environments are compatible: some highly restricted platforms may prevent a full scan.

When to contact Securantis support

Contact support if:

• You followed the steps and the scan remains stuck with no clear message in the logs.
• The job fails with server-side errors you cannot fix (processes killed, system permissions, unreliable network storage).
• You observe major detections and need help analyzing files (support can advise, but any quarantining/restoration action will remain under your control).

What to provide to support (no passwords)

• Screenshots of the scan status and error messages.
• Extracts of agent/module logs and PHP/web logs (without sensitive information like passwords).
• Description of the hosting (shared, VPS, storage type) and current PHP limits.

Conclusion

A interrupted scan is most often related to execution limits or a non-operational task mechanism. Prefer incremental / background-compatible mode on constrained hosting, temporarily increase limits if you can, and monitor load. For persistent blockage, Securantis support can help analyze logs; the decision to quarantine or delete files will always remain yours.