NetBSD Problem Report #60622

From www@netbsd.org  Thu Aug 20 15:04:37 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 "YR2" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id B7A2C1A923B
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 20 Aug 2026 15:04:37 +0000 (UTC)
Message-Id: <20260820150436.579521A923C@mollari.NetBSD.org>
Date: Thu, 20 Aug 2026 15:04:36 +0000 (UTC)
From: thorpej@me.com
Reply-To: thorpej@me.com
To: gnats-bugs@NetBSD.org
Subject: syslogd rc.d script is slow, does too much work in the common case
X-Send-Pr-Version: www-1.0
X-From4GNATS: "thorpej@me.com via gnats" <gnats-admin@NetBSD.org>

>Number:         60622
>Category:       bin
>Synopsis:       syslogd rc.d script is slow, does too much work in the common case
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 20 15:05:01 +0000 2026
>Originator:     Jason Thorpe
>Release:        NetBSD 11.99.7
>Organization:
Retrogrouches'R'Us
>Environment:
NetBSD icarus 11.99.7 NetBSD 11.99.7 (PHAETHON1) #154: Fri Aug  7 14:45:49 PDT 2026  thorpej@dhcp-105.ktnet:/Users/thorpej/NetBSD/current/src/sys/arch/hb68k/compile/PHAETHON1 hb68k

icarus# sysctl hw.machine_arch
hw.machine_arch = m68000
icarus# 

Issue also observed on NetBSD/shark and NetBSD/alpha.
>Description:
The syslogd rc.d script performs a bunch of work that not needed in the common (i.e. default) case.

The syslogd script provides a precmd that does:

- Installation of transitional symlink to accommodate old syslogd binaries.
- Creation and population of a socket list file that specifies the sockets syslogd should listen to.  This file is to accommodate services that run in a chroot environment.

The former step seems unnecessary (you're installing a new rc.d script for syslogd without installing a new syslogd binary?)

The latter step is where the expense is.  The script runs rcorder to obtain a list of services that specify the "chrootdir" keyword, and then does an is-enabled check.  Each one of these is-enabled checks is done within a subshell.  If is-enabled is true, then the service's chroot environment is added to the list of syslogd sockets.

In addition to being unnessary work in the common case where you're not running a bunch of chroot'd services, those is-enabled checks are actually not strictly correct, making assumptions about the conventions those scripts use.  It also misses scripts if additional rc_directories are configured.
>How-To-Repeat:
Boot a slow system.  Wonder why "syslogd" takes so long.
>Fix:
Not provided here.  Ultimately, I think a discussion should be had about where a new mechanism should be provided for communication with syslogd that doesn't require a plethora of file system objects to be created just to accommodate services running in a chroot environment.

Home	PR Database Search