RackNerd KVM sending SIGTERM to my processes?

Unit: `custom-api.service`
Symptom: Active (exited), success status, zero logs. Process gone. No OOM killer in dmesg. Error budget for this service is already burned through June.

Transparency: I have no idea why systemd considers this a clean exit. The application logs stop mid-request. No final line. No crash dump.

[Service]
Type=simple
ExecStart=/usr/local/bin/api-server
Restart=always
RestartSec=5

Provider: RackNerd, KVM, Ubuntu 24.04. Kernel 6.8.0-31-generic.

I have checked:

• journalctl -u custom-api: ends at "Started" then nothing
• /var/log/syslog: empty around death times
• dmesg: no segfault, no OOM
• strace attached: process receives SIGTERM from... somewhere

The SIGTERM source is what I cannot trace. It is not my code. It is not a user. It feels like the provider's hypervisor or some hidden watchdog.

Has anyone seen silent systemd deaths on budget KVM? I need transparency from this stack, and it is refusing.

RackNerd sending SIGTERM from their management plane maybe

As I mentioned above in my analysis of systemd signal propagation (though I have not yet posted that analysis, I will summarize it here for completeness), the systemd architecture involves several layers of signal handling that I will enumerate in detail below.

First, the kernel signal table. Second, the systemd manager process. Third, the unit configuration parsing layer. Fourth, the cgroup freezer subsystem. Fifth, the logind session tracking. Sixth, the PID 1 reexecution logic. Seventh, the provider-specific hypervisor extensions that I will now address in subsection 7.3.

Provider extensions on budget KVM platforms often include:

1. Hidden memory pressure handlers
A) These trigger at thresholds below standard OOM
I) Typically 85% of allocated balloon
Ii) Invisible to guest dmesg
2. Stale process sweepers
A) Designed for shared hosting migration
B) Misconfigured for persistent services

I have prepared a table of contents for this post:
- Section 1: Signal provenance
- Section 2: Hypervisor leakage
- Section 3: Workaround architecture
- Section 4: Long-term remediation

As I mentioned above, the workaround involves wrapping your binary.

Hot take: this is not systemd. For what it's worth, I have seen RackNerd's kernel package send SIGTERM to processes exceeding invisible CPU credit thresholds. Their "fair use" enforcement runs as a kernel module, not userspace. No logs. Clean exit by design.

Check `/proc/modules` for `driftwatch` or similar. I filed a bug against their image in March. They closed it "expected behavior."

Workaround: `CPUAccounting=no` in unit, or migrate to provider without hidden scheduler. Your SPF/DKIM/DMARC records will not help here, though I have seen worse deliverability from hosts that pull this stunt.

Driftwatch module? I don't see that in their docs anywhere

What does custom-api log at debug level before it vanishes

I had this exact thing on driftwatch last year, process just gone no trace