masscan output file empty after authorized scan failed to write results

TL;DR

Masscan holds results in memory and writes the output file when the scan finishes, so a crash, a kill, or a full disk leaves a 0-byte file. Always write a live text log alongside the binary output, then re-run in smaller rate-limited chunks so a failure costs minutes instead of the whole scan.

(output file is 0 bytes after masscan exits abnormally)

Use this when

• -oB scan.bin or -oX scan.xml exists but is empty after an interrupted authorized scan.
• You need the partial results back or a safe way to re-run.

Not for this skill when

• Masscan completed and reported zero open ports. An empty result set is a finding, not this bug.
• The file has content but will not parse. That is corruption, a different fix.

Steps

1. Confirm the file is truly empty and the scan died early: ls -la scan.bin, and check whether any masscan process is still alive. Verify: 0 bytes and no running process means the flush never happened.
2. Check the boring causes first: df -h on the output filesystem and write permission on the directory. Verify: the disk is not full and the file is writable before re-running.
3. Re-run with dual outputs: -oB scan.bin -oL scan.log. Verify: the text log grows during the scan, so even another crash leaves you the live results.
4. Split the range and lower the rate: scan the subnet in halves at a moderate rate instead of one giant fast run. Verify: each chunk finishes and writes its own complete file.
5. Merge chunk logs by concatenating the text logs and de-duplicating the host and port lines. Verify: the merged set matches the sum of the chunk counts.

Variant phrasings

masscan binary output empty file

The -oB-specific phrasing.

masscan killed output not saved

The interrupted-scan phrasing.

masscan xml output 0 bytes

The -oX-specific phrasing.

Compatibility: masscan 1.3.x. The binary, XML, and list outputs all flush at exit; only the list log streams usefully during the run.

Why it happens

For speed, masscan buffers everything and serializes once at clean exit. An out-of-memory kill, a closed laptop lid, or a full disk skips that final write entirely. The scan did the work; the evidence just never landed on disk.

Edge cases / pitfalls

• The text log is lossier than the binary output, with fewer fields per record. Keep both when the binary format matters for your pipeline.
• Re-running the same huge range at the same rate invites the same crash. Change something, rate, chunks, or box memory, or expect a repeat.
• An empty output file plus a completed-looking log line can fool an agent into reporting "no open ports". Check the exit status before trusting the file.
• Note the failure in the engagement log: a re-run that silently replaces a crashed run hides the instability from the report reviewer.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xycAOFOhpnsuWWuoqHEVpg