IL-20: AI Service Scripts Did Not Verify Start or Stop

GPT-5.6-sol wrote two service scripts that could lose track of the resource they controlled. One trusted a saved process ID without checking whether it still belonged to the web server. In a separate swap task, startup selected an available zram device, but shutdown always targeted /dev/zram0.

The agent ran administrative shell commands in both jobs. The recorded starts succeeded; the problems described below follow from the scripts’ behavior when a process ID or device allocation changes.

The repository script treated an existing PID as the service

Legacy local repository task prompt (verbatim):

On `node1`, serve a package repository from local storage and install a package from it while the usual remote repositories are unreachable. Keep the installed operating-system release and kernel; use software compatible with this legacy platform.

On Ubuntu 7.10, the agent used a SysV init script to manage a Python SimpleHTTPServer on port 8080. That server provided the local package repository.

The delivered script used kill -0 with a number read from its PID file to decide whether the service was already running. That operation checks whether a process number exists and is signalable. It does not establish the executable or socket readiness.

If the server exits and leaves its PID file behind, Linux may later assign that PID to an unrelated process. The script’s kill -0 check would then succeed, and the script could report that the repository server was running even though it had stopped.

The swap helper did not retain the device it allocated

Compressed swap task prompt (verbatim):

On `node1`, add at least 512 MB of compressed in-memory swap, active at boot and preferred over any disk-backed swap.

The separate swap job used Ubuntu 24.04.3 and started with no active swap. The agent wrote a systemd unit to create and activate a zram device.

The revised unit used zramctl --find to choose an available device and passed that returned path to mkswap and swapon. Its stop directives instead always selected:

ExecStop=-/usr/sbin/swapoff /dev/zram0
ExecStop=-/usr/sbin/zramctl --reset /dev/zram0

During the recorded run, startup selected /dev/zram0, so the start and stop paths referred to the same device. The requested 512 MiB of high-priority swap was active after reboot.

Both scripts depended on identities that could change

The repository served a package and returned after reboot. The swap unit also worked in the tested starting state. The scripts nevertheless used a saved PID or a fixed device name as a substitute for tracking the resource they had started.

For example, if another zram device occupied /dev/zram0, startup could select /dev/zram1. Shutdown would still disable and reset /dev/zram0, leaving the unit’s own swap device active and targeting a different one.