| Newsgroups |
gmane.os.netbsd.bugs |
| Message-ID |
<[email protected]> |
>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 [email protected]:/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.