NetBSD Problem Report #60237

From www@netbsd.org  Thu May  7 23:42:51 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R13" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 662311A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  7 May 2026 23:42:51 +0000 (UTC)
Message-Id: <20260507234250.663151A923A@mollari.NetBSD.org>
Date: Thu,  7 May 2026 23:42:50 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: inetd(8) has no way to reconfigure stream wait processes
X-Send-Pr-Version: www-1.0
X-From4GNATS: "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>

>Number:         60237
>Category:       bin
>Synopsis:       inetd(8) has no way to reconfigure stream wait processes
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 07 23:45:01 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, 11, 10, 9, ...
>Organization:
The inetgizer Bunny
>Environment:
>Description:

	If you configure a stream-type wait-mode service in
	/etc/inetd.conf, inetd(8) will eagerly bind a listening socket
	and then lazily spawn a subprocess with the listening socket
	passed as fd 0 when the first client tries to connect to it.

	However, while inetd(8) can reload its configuration file on
	SIGHUP and update all other types of services, I can't find any
	path by which it will kill and restart stream-type wait-mode
	services.

	Of course, I can dig through ps(1) output to find the service's
	pid to kill outside inetd(8), but that's not reliable (could
	exit and have its pid recycled, for instance) and inetd(8)
	won't wait for the child to exit before starting a new
	instance (which is important for process limits).

>How-To-Repeat:

	code contemplation

>Fix:

	Yes, please!  Perhaps inetd(8) should send SIGTERM (and maybe
	SIGKILL after a delay) to the child.  Perhaps inetd(8) should
	put the child in its own process group and send SIGTERM to the
	process group.  Perhaps we should ship a more elaborated
	process supervisor with socket activations.  Perhaps we should
	have a pony.

Home	PR Database Search