>Synopsis: rc.subr: spurious "kill: <pid>: no such process" on start with
>rc_bg=YES
>Category: system
>Environment:
System : OpenBSD 7.9
Details : OpenBSD 7.9 (GENERIC.MP) #15: Sun Sep 27 02:47:36 MDT 2026
[email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
When starting a package daemon whose rc.d script sets rc_bg=YES,
the following message is sometimes printed at boot:
Starting package daemons: oficina/etc/rc.d/oficina: kill: 68044: no such
process
The daemon starts correctly and "rcctl check oficina" reports ok,
so the problem is cosmetic.
The message comes from rc_cmd() in /etc/rc.d/rc.subr (rev 1.167,
identical to -current):
_rc_do _rc_wait_for_start & _TIMERSUB=$!
trap "_rc_alarm" ALRM
_rc_do rc_start; _ret=$?
kill -ALRM ${_TIMERSUB}
With rc_bg=YES, rc_start returns immediately. If rc_check already
succeeds inside _rc_wait_for_start, the loop breaks, the subshell
runs "pkill -ALRM -P $$" and exits, so the later
"kill -ALRM ${_TIMERSUB}" targets a process that no longer exists
and prints an error.
_rc_alarm() already handles this case for the same PID and
discards the error ("timer may not be running anymore"), but the
kill in rc_cmd() does not.
The message started appearing after applying the latest 7.9
syspatches. None of them modify rc.subr (checked the rollback.tgz
files under /var/syspatch), so they most likely only changed the
timing enough to expose the race on this slow machine
(Pentium Dual-Core E2140 @ 1.60GHz, 2 GB RAM).
For context, "oficina" is a small in-house application, not an
OpenBSD port or package: a Node.js (NestJS) HTTP backend for a
workshop management project, deployed under /var/oficina and
started with node from packages. It listens on 127.0.0.1:3000
behind nginx, runs as an unprivileged user without a shell, and
does not daemonize itself, hence rc_bg=YES, with its output sent
to syslog through daemon_logger.
The rc.d script in use:
#!/bin/ksh
daemon="/usr/local/bin/node"
daemon_flags="/var/oficina/dist/main"
daemon_user="_oficina"
daemon_execdir="/var/oficina"
daemon_logger="daemon.info"
. /etc/rc.d/rc.subr
rc_bg=YES
rc_cmd $1
>How-To-Repeat:
Enable a package daemon using rc_bg=YES that becomes visible to
rc_check quickly (e.g. a node application) and reboot. The message
is timing dependent and does not appear on every boot; it shows
up more readily on slow hardware.
>Fix:
Discard the error, consistently with _rc_alarm():
--- etc/rc.d/rc.subr Wed May 6 18:44:19 2026
+++ etc/rc.d/rc.subr Wed Sep 30 07:57:25 2026
@@ -256,7 +256,7 @@
_rc_do _rc_wait_for_start & _TIMERSUB=$!
trap "_rc_alarm" ALRM
_rc_do rc_start; _ret=$?
- kill -ALRM ${_TIMERSUB}
+ kill -ALRM ${_TIMERSUB} 2>/dev/null
wait ${_TIMERSUB} 2>/dev/null # don't print Alarm clock
# XXX for unknown reason, rc_check can fail (e.g. redis)
# while it just succeeded in _rc_wait_for_start;
The analysis of this issue was done with the help of Claude
(Anthropic's AI assistant, model Claude Opus 5.5).
