Campaign: High Number of Zombie Processes on web@default

A monitoring alert reported an unusually high number of zombie processes on an Adobe Campaign instance. The count reached 23, while the monitoring indicator displayed a maximum value of 2. Investigation confirmed that the processes were harmless operating-system-level defunct shell helpers created by normal background audience-load activity.

Description description

The monitoring system identified multiple [ sh] < defunct> processes associated with the web@default parent process. The reported count was higher than the displayed maximum threshold:

Current count: 23 zombie processes
Monitoring threshold: 2 processes
Parent process: web@default
Process pattern: Bursts of short-lived /bin/sh helper processes

A restart of web@default cleared the processes temporarily, but similar processes could appear again after subsequent background jobs completed.

The investigation found no evidence of stuck jobs, looping processes, failed audience synchronization, or functional degradation.

Resolution resolution

Root Cause

Adobe Campaign runs certain background and out-of-process jobs by launching short-lived shell helpers, such as:

/bin/sh -c “nlserver job …”

The investigation traced the defunct processes to normal CDP/AEP audience-load activity, including nms:groupLoadJob audience synchronization jobs. These jobs frequently run on the instance and may create multiple helper processes in a short period.

When several helpers finish concurrently, the web@default child-process reaper can intermittently miss collecting their exit statuses. The completed child processes then remain in the process table as zombies until they are reaped or the parent process exits.

The displayed value of 2 is not a hard limit on the number of zombie processes. It is the warning threshold configured in the server-monitoring script. Any count above 2 causes the monitoring indicator to turn red.

Impact

The zombie processes were benign:

They consumed no CPU.
They consumed no memory.
They held only process identifiers in the operating-system process table.
They did not affect deliveries, workflows, audience loads, or the web user interface.
The observed count was far below any realistic risk of exhausting the host process table.
The alert was therefore cosmetic and did not indicate a Campaign processing failure.

Resolution

Engineering confirmed that no manual remediation was required.

The web@default process is configured to restart automatically each day at approximately 06:01. This restart clears any remaining zombie processes because the operating system reaps the child processes when their parent exits.

Zombie processes are already terminated and cannot be meaningfully killed or timed out. They are removed when the parent process collects their exit status or terminates. In this case, the scheduled daily restart provides automatic cleanup.

The issue was resolved as a harmless side effect of normal, high-volume audience-load activity. No changes to audience synchronization, Campaign workflows, or customer configuration were necessary.