TeX macro expansion engine and pdfTeX driver: \write18 shell-escape blocking under restricted mode

The short answer: in restricted shell-escape mode, pdfTeX does not block on your external command at all — it never runs it. The \write18 token is expanded to empty text during token processing, the shell call is silently dropped, and compilation proceeds. If you are seeing a stall that looks like resource exhaustion, that stall is almost certainly not caused by restricted mode; it is either an unrestricted-mode \write18 whose child process is genuinely long-running, or an unrelated I/O or memory problem. The two failure modes are distinguishable, and the rest of this answer explains how.

What actually happens in each mode

TeX's macro expansion engine and the pdfTeX output driver are only loosely coupled: \write18 is expanded during token processing, before any page is shipped out, and pdfTeX buffers page content until a page completes. Two consequences follow:

• Restricted mode (the default since roughly 2020): the \write18 expands to nothing. No subprocess is spawned, nothing appears in ps or system monitors, and the log contains no shell-invocation line. Expected side effects (generated files, fetched data) simply never happen.
• Unrestricted mode: pdfTeX spawns the shell synchronously and waits for it to exit. A long-running child blocks the main TeX process mid-expansion, which from the outside mimics memory exhaustion or an I/O hang — high wait time, no log progress, no error.

Log signatures: blocked shell vs. genuine exhaustion

The reliable discriminator is the absence of evidence, checked deliberately:

1. Search the log for any shell-escape line (runsystem(...), "written to shell", or engine-specific variants). No such line plus missing side effects means restricted mode dropped the call — nothing was ever blocked.
2. If a shell line is present and the log then goes silent, pdfTeX is waiting on the child. Confirm at the OS level: ps aux | grep pdftex and look for the child process in the same process tree.
3. Genuine exhaustion looks different: pdfTeX emits ! TeX capacity exceeded or the OS OOM-killer logs a kill. Those are errors, not hangs.

Detecting whether shell escape is really active

Do not trust the "Shell escape enabled" banner alone — wrapper scripts and redirected output can suppress it, and site security policies can override the setting at runtime. Verify empirically with a probe document:

\immediate\write18{echo ok > /tmp/tex_escape_probe}
\bye

Compile it, then check whether /tmp/tex_escape_probe exists. Presence proves unrestricted execution; absence proves the call was dropped. For a build system, run this probe once in a setup step and gate the real build on the result, rather than parsing logs. You can also force intent explicitly with -shell-escape or -no-shell-escape so the mode is a decision, not an environment accident.

Timeouts and engine differences

There is no documented pdfTeX-level timeout for \write18: the engine waits until the child exits, and process-group behavior is inherited from the invoking shell. If you need a bound, impose it yourself — wrap the command in timeout 60s ... (GNU coreutils) or have your build system kill the whole process group. Note also that XeTeX and LuaTeX route shell escape through different handlers, so the restricted-mode silencing described here is verified for pdfTeX and should be re-probed per engine rather than assumed identical.

Recommended resolution for your case

1. Run the probe document above to establish the actual mode.
2. If restricted and the side effects are required, opt in explicitly with -shell-escape on a trusted build host only.
3. If unrestricted and builds hang, instrument the external command with timeout and log its start/end times so a future stall is attributable to the child, not the engine.

One caveat for review: exact log wording (runsystem vs. other formats) varies by TeX Live release, so confirm the banner strings against your installed version before hard-coding log parsing.