nmap grepable output file empty after scan of authorized scope completed

Not specified by the original author.

TL;DR

Grepable output is written at the end of the run and is the first casualty when a scan is interrupted, the disk fills, or the deprecated -oG format drops data on newer builds. Rerun the in-scope scan writing -oA or at least -oX and -oN together, and derive any grepable view from the XML instead of trusting -oG alone.

nmap grepable output file empty after scan of authorized scope completed

Use this when

• The -oG file for a finished authorized scan is empty or missing host lines that appeared on screen.
• A wrapper script parsed zero hosts from grepable output after a scan that clearly ran.

Not for this skill when

• The scan reported zero hosts up on an empty range. Empty output is then the correct result.
• The file is fine but the parser expects XML. That is a parser format problem, not lost output.

Steps

1. Check the basics first: file size, disk space on the output volume, and whether the scan process was killed or the laptop slept mid-run. Verify: Verify: you can say whether the run completed cleanly and had space to write.
2. Look for sibling outputs from the same run; if an XML file exists, count its host entries and compare with what the console showed. Verify: Verify: the XML host count matches the console, proving the scan data survived.
3. Rerun the authorized scan with -oA basename so normal, XML, and grepable files are written together. Verify: Verify: all three files are non-empty and agree on host and port counts.
4. On current nmap builds, treat grepable as legacy: convert the XML to the tabular view your reporting step needs instead of parsing -oG. Verify: Verify: the converted view lists the same open ports as the XML.
5. Add a post-scan check to the engagement workflow: fail loudly if an output file is zero bytes while the exit target count was non-zero. Verify: Verify: a deliberately truncated test file trips the check.

Variant phrasings

nmap -oG empty file but scan found hosts

The mismatch phrasing when the console showed results.

grepable output deprecated missing ports nmap

The format-limitation phrasing on newer builds.

nmap output lost after scan completed

The broader lost-results phrasing.

Compatibility: Compatibility: nmap 7.x; grepable output is deprecated upstream, XML output is the stable interchange format.

Why it happens

Grepable output was designed for one-line-per-host shell parsing and is buffered until hosts finish. Interruption, a full disk, or format edge cases on modern builds can leave it empty while the scan itself succeeded. XML is written incrementally per host and carries strictly more detail, which is why it survives as the reliable record.

Edge cases / pitfalls

• A resume of an interrupted scan appends oddly to grepable files; start a fresh basename for the rerun and keep both runs labelled.
• Do not re-scan a whole authorized range just to rebuild a file if the XML exists; convert first, scan again only if every output is gone.
• Wrappers that silently accept an empty file will under-report coverage; the loud check in step 5 is the durable fix.

Provenance

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

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

Thread query: nmap grepable output file empty after scan of authorized scope completed

TL;DR: Grepable output is written at the end of the run and is the first casualty when a scan is interrupted, the disk fills, or the deprecated -oG format drops data on newer builds. Rerun the in-scope scan writing -oA or at least -oX and -oN together, and derive any grepable view from the XML instead of trusting -oG alone.

Not specified by the original author.

TL;DR

nmap writes the XML file only when the scan finishes, so a crash leaves it truncated or empty. Check whether the normal (-oN) or grepable (-oG) output survived, salvage what you can from it, then re-run the scan in smaller chunks with a separate output file per chunk so one crash cannot take the whole run.

nmap: XML output file truncated / empty after scan aborted

Use this when

• The -oX file is empty, truncated, or fails to parse after a crash.
• You still need results for the authorized scope.
• The crash killed nmap itself (OOM, box reboot, killed process).

Not for this skill when

• The XML parses fine. A parsing complaint from your own script is a different bug.
• The scan finished. Then the output is complete by definition.

Steps

1. Check what actually survived: ls -la scan.* and tail -5 scan.nmap. The normal output file is written incrementally and often has partial results. Verify: you know which output files have usable data.
2. Salvage host and port lines from the normal output: grep -E "Nmap scan report|open" scan.nmap. Verify: you recover the hosts that completed before the crash.
3. Re-run in chunks so a repeat crash costs minutes, not hours: nmap -sS -oA chunk1 192.0.2.0/25. Verify: each chunk writes its own .nmap, .xml, and .gnmap on completion.
4. Merge chunk XML only from files that parse: python3 -c "import xml.dom.minidom; xml.dom.minidom.parse('chunk1.xml')". Verify: every merged file is well-formed before you combine them.
5. Find the crash cause before the next big run: check dmesg | grep -i oom for out-of-memory kills, the usual suspect on small test VMs. Verify: you fixed the cause, not just the symptom.

Compatibility: nmap 7.x. -oA behavior is unchanged across recent versions.

Variant phrasings

nmap xml output empty after crash

Same fix path, common phrasing.

nmap scan crashed no xml results

Symptom-level search.

recover nmap partial results crashed scan

The salvage-oriented search.

Why it happens

nmap buffers the XML document in memory and writes it at the end of the run, while the normal text output streams to disk as hosts complete. A crash between those two moments leaves a truncated XML file and a usable text file. This is by design for XML validity: a half-written XML file would be worse than none.

Edge cases / pitfalls

• -oG grepable output is also incremental and easy to re-parse. Prefer it for chunked runs your scripts consume.
• The .gnmap file may claim a host "up" that never got its ports scanned. Cross-check with the .nmap text.
• If OOM is the cause, reduce parallelism with --max-parallelism rather than just re-running.
• Log the crash and the salvage in your report methodology. Partial coverage is a finding about the engagement, not just your tooling.

Provenance

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

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

Thread query: nmap XML output corrupt after scan of authorized target crashed mid-run

TL;DR: nmap writes the XML file only when the scan finishes, so a crash leaves it truncated or empty. Check whether the normal (-oN) or grepable (-oG) output survived, salvage what you can from it, then re-run the scan in smaller chunks with a separate output file per chunk so one crash cannot take the whole run.

Not specified by the original author.

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

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

Thread query: 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.