NetBSD Problem Report #58091
From www@netbsd.org Sat Mar 30 13:31:46 2024
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))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 95CA11A923B
for <gnats-bugs@gnats.NetBSD.org>; Sat, 30 Mar 2024 13:31:46 +0000 (UTC)
Message-Id: <20240330133145.957871A923C@mollari.NetBSD.org>
Date: Sat, 30 Mar 2024 13:31:45 +0000 (UTC)
From: michael.dusan@gmail.com
Reply-To: michael.dusan@gmail.com
To: gnats-bugs@NetBSD.org
Subject: after fork/execve or posix_spawn, parent kill(child, SIGTERM) has race condition making it unreliable
X-Send-Pr-Version: www-1.0
>Number: 58091
>Notify-List: riastradh@NetBSD.org
>Category: kern
>Synopsis: after fork/execve or posix_spawn, parent kill(child, SIGTERM) has race condition making it unreliable
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: riastradh
>State: needs-pullups
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Mar 30 13:35:00 +0000 2024
>Closed-Date:
>Last-Modified: Sat Jun 27 17:15:58 +0000 2026
>Originator: Michael Dusan
>Release:
>Organization:
Zig Software Foundation
>Environment:
NetBSD netbsd100-amd64 10.0_RC6 NetBSD 10.0_RC6 (GENERIC) #0: Tue Mar 12 10:19:02 UTC 2024 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
NetBSD netbsd93-amd64 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug 4 15:30:37 UTC 2022 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
Fork/exec a child and first action of parent, send SIGTERM to child and ~3 out of million times the signal is never received by child.
Variant using posix_spawn tends to manifest much more frequently on netbsd 10.0 RC6, and more frequently on netbsd 9.3 .
Unable to reproduce this bug on archlinux, macos 14.0, freebsd 14.4,, openbsd 7.4, dragonfly 6.4 .
Using ktrace, I was able to see the bug (with the motivating .zig programming language code for this bug report) much more frequently and observed that the closer parent `kill()` call is in ktrace output to the child calling `execve()`, ie: immediately preceding, this bug manifests.
It seems that the signal is lost somewhere in kernel execve preparation.
>How-To-Repeat:
0. caution: running this bug may hose the system. In another incarnation it would end my ssh session (and other sessions to same netbsd system), requiring a reboot
1. see affixed but.c code
2. cc -o bug bug.c
3. in shell `repeat 1000 ./bug`
4. over time, the output "whups" indicates child did not end due to signal
5. it sometimes help to busy the sytem, eg. concurrently run step #3 in another shell
6. I usually observe 2 or 3 "whups" per invocation
7. testing env 1: qemu VM netbsd 10.0_RC6 as "8 core" guest
8. testing env 2: qemu VM netbsd 9.3 amd64 as "8 core" guest
9. VM host: archlinux, AMD Ryzen 9 7900X 12-Core Processor
///////////////////////////////////////////////////////////////////////////////
// bug.c
#include <errno.h>
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
void doit() {
pid_t pid = fork();
if (pid == 0) {
char *argv[] = { "sleep", "10", NULL };
int res = execve("/bin/sleep", argv, NULL);
} else {
// we are parent
if (kill(pid, SIGTERM) == -1) {
fprintf(stderr, "kill: errno=%d\n", errno);
return;
}
int status;
if (waitpid(pid, &status, 0) == -1) {
fprintf(stderr, "kill: errno=%d\n", errno);
return;
}
if (!WIFSIGNALED(status)) {
fprintf(stderr, "whups!\n");
}
}
}
int main() {
for (int i = 0; i < 1000; i++) {
doit();
}
}
///////////////////////////////////////////////////////////////////////////////
// bug_posix.c
// this variant uses `posix_spawn()` instead of fork/execve
// here it's set to do 1 million iterations
// netbsd 10.0_RC3 emits "whups" over a hundred times on average
// netbsd 9.3 emits "whups" maybe 20 times on average
#include <errno.h>
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
#include <spawn.h>
#include <sys/wait.h>
void doit() {
char *argv[] = { "sleep", "1", NULL };
pid_t pid;
if (posix_spawn(&pid, "/bin/sleep", NULL, NULL, argv, NULL) == -1) {
fprintf(stderr, "posix_spawn: errno=%d\n", errno);
return;
}
if (kill(pid, SIGTERM) == -1) {
fprintf(stderr, "kill: errno=%d\n", errno);
return;
}
int status;
if (waitpid(pid, &status, 0) == -1) {
fprintf(stderr, "kill: errno=%d\n", errno);
return;
}
if (!WIFSIGNALED(status)) {
fprintf(stderr, "whups!\n");
}
}
int main() {
for (int i = 0; i < 1000000; i++) {
doit();
}
}
>Fix:
>Release-Note:
>Audit-Trail:
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58091 CVS commit: src
Date: Thu, 13 Mar 2025 01:27:28 +0000
Module Name: src
Committed By: riastradh
Date: Thu Mar 13 01:27:27 UTC 2025
Modified Files:
src/distrib/sets/lists/debug: mi
src/distrib/sets/lists/tests: mi
src/tests/lib/libc/gen: Makefile
src/tests/lib/libc/gen/execve: t_execve.c
src/tests/lib/libc/gen/posix_spawn: t_spawn.c
Added Files:
src/tests/lib/libc/gen: h_execsig.c
Log Message:
execve(2), posix_spawn(2): Add test case for an embarrassing bug.
PR kern/58091: after fork/execve or posix_spawn, parent kill(child,
SIGTERM) has race condition making it unreliable
To generate a diff of this commit:
cvs rdiff -u -r1.468 -r1.469 src/distrib/sets/lists/debug/mi
cvs rdiff -u -r1.1360 -r1.1361 src/distrib/sets/lists/tests/mi
cvs rdiff -u -r1.56 -r1.57 src/tests/lib/libc/gen/Makefile
cvs rdiff -u -r0 -r1.1 src/tests/lib/libc/gen/h_execsig.c
cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libc/gen/execve/t_execve.c
cvs rdiff -u -r1.8 -r1.9 src/tests/lib/libc/gen/posix_spawn/t_spawn.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->analyzed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 13 Mar 2025 01:54:36 +0000
State-Changed-Why:
This turns out to be a rather embarrassing self-inflicted bug where
execve(2) and posix_spawn(2) first carefully discard only those pending
signals whose dispositions are being reset to a default action of being
ignored (e.g., SIGCHLD, SIGWINCH, ...)...and then, in a separate
subroutine, just blithely discard _all_ pending signals anyway. The
two subroutines were written at different times, which explains some of
the confusion, and one of them can be entirely deleted, which I will do
once the releng test bed runs the new tests I added for this.
Sorry for the delay in handling this issue -- it escaped our attention
when it first turned up, apparently, or whoever investigated when it
first arrived came up empty-handed and didn't pursue it.
Responsible-Changed-From-To: kern-bug-people->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Thu, 13 Mar 2025 01:55:53 +0000
Responsible-Changed-Why:
mine
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58091 CVS commit: src/tests/lib/libc/gen
Date: Thu, 13 Mar 2025 09:40:03 +0000
Module Name: src
Committed By: riastradh
Date: Thu Mar 13 09:40:03 UTC 2025
Added Files:
src/tests/lib/libc/gen: Makefile.inc
Log Message:
execve(2), posix_spawn(2): Fix build of tests after previous.
Forgot to add a file.
PR kern/58091: after fork/execve or posix_spawn, parent kill(child,
SIGTERM) has race condition making it unreliable
To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/tests/lib/libc/gen/Makefile.inc
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58091 CVS commit: src
Date: Thu, 13 Mar 2025 12:48:22 +0000
Module Name: src
Committed By: riastradh
Date: Thu Mar 13 12:48:22 UTC 2025
Modified Files:
src/sys/kern: kern_sig.c
src/tests/lib/libc/gen/execve: t_execve.c
src/tests/lib/libc/gen/posix_spawn: t_spawn.c
Log Message:
execve(2), posix_spawn(2): Don't flush _all_ pending signals.
We need only flush those pending signals whose dispositions have been
reset to the default action when that action is to ignore them --
e.g., if the parent had a signal handler function for SIGCHLD or
SIGWINCH, this is reset to the default disposition, which is to
ignore the signal, so any pending SIGCHLD or SIGWINCH need to be
flushed.
And we have logic to do this already in execsigs(9), via
sigclearset(9), which clears the specified set of signals:
402 sigemptyset(&tset);
403 for (signo = 1; signo < NSIG; signo++) {
404 if (sigismember(&p->p_sigctx.ps_sigcatch, signo)) {
405 prop = sigprop[signo];
406 if (prop & SA_IGNORE) {
407 if ((prop & SA_CONT) == 0)
408 sigaddset(&p->p_sigctx.ps_sigignore,
409 signo);
410 sigaddset(&tset, signo);
411 }
412 SIGACTION_PS(ps, signo).sa_handler = SIG_DFL;
...
420 sigclearall(p, &tset, &kq);
https://nxr.netbsd.org/xref/src/sys/kern/kern_sig.c?r=1.409#394
But back in 2003, when ksiginfo_t was introduced, before that logic
was written, we sprouted an exithook to clear _all_ the signals (and,
more importantly for the time, free the ksiginfo_t records to avoid
leaking memory) -- and we wired it up as an _exechook_ too:
+/*
+ * free all pending ksiginfo on exit
+ */
+static void
+ksiginfo_exithook(struct proc *p, void *v)
+{
+ ksiginfo_t *ksi, *hp = p->p_sigctx.ps_siginfo;
+
+ if (hp == NULL)
+ return;
+ for (;;) {
+ pool_put(&ksiginfo_pool, ksi);
+ if ((ksi = ksi->ksi_next) == hp)
+ break;
+ }
+}
...
+ exithook_establish(ksiginfo_exithook, NULL);
+ exechook_establish(ksiginfo_exithook, NULL);
https://mail-index.netbsd.org/source-changes/2003/09/14/msg133910.html
(The first iteration of ksiginfo_exithook had another bug, of course!
But it was soon fixed; that's not the issue here.)
Later, during the newlock2 branch, sigclearall got added for execsigs
to free only the ksiginfo_t records for those signals whose
disposition is being reset to a default action of ignoring the
signal:
void
execsigs(struct proc *p)
{
...
+ sigset_t tset;
...
- for (signum = 1; signum < NSIG; signum++) {
- if (sigismember(&p->p_sigctx.ps_sigcatch, signum)) {
- prop = sigprop[signum];
+ sigemptyset(&tset);
+ for (signo = 1; signo < NSIG; signo++) {
+ if (sigismember(&p->p_sigctx.ps_sigcatch, signo)) {
+ prop = sigprop[signo];
if (prop & SA_IGNORE) {
if ((prop & SA_CONT) == 0)
sigaddset(&p->p_sigctx.ps_sigignore,
- signum);
- sigdelset(&p->p_sigctx.ps_siglist, signum);
+ signo);
+ sigaddset(&tset, signo);
...
}
+ sigclearall(p, &tset);
https://mail-index.netbsd.org/source-changes/2006/10/21/msg176390.html
And the _exithook_ was removed somewhere along the way in the
newlock2 branch (in favour of simply calling sigclearall in exit1),
but the _exechook_ remained:
-static void ksiginfo_exithook(struct proc *, void *);
+static void ksiginfo_exechook(struct proc *, void *);
...
- exithook_establish(ksiginfo_exithook, NULL);
- exechook_establish(ksiginfo_exithook, NULL);
+ exechook_establish(ksiginfo_exechook, NULL);
...
/*
- * ksiginfo_exithook:
+ * ksiginfo_exechook:
*
- * Free all pending ksiginfo entries from a process on exit.
+ * Free all pending ksiginfo entries from a process on exec.
* Additionally, drain any unused ksiginfo structures in the
* system back to the pool.
+ *
+ * XXX This should not be a hook, every process has signals.
*/
static void
-ksiginfo_exithook(struct proc *p, void *v)
+ksiginfo_exechook(struct proc *p, void *v)
{
https://mail-index.netbsd.org/source-changes/2007/02/05/msg180796.html
The symptom of this mistake is that a signal delivered _during_
execve(2) may be simply discarded, even if it should be caught and
cause the process to terminate.
On the bright side, isn't it a nice feeling when you can solve
problems by commits that consist exclusively of deletions?
PR kern/58091: after fork/execve or posix_spawn, parent kill(child,
SIGTERM) has race condition making it unreliable
To generate a diff of this commit:
cvs rdiff -u -r1.409 -r1.410 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.3 -r1.4 src/tests/lib/libc/gen/execve/t_execve.c
cvs rdiff -u -r1.9 -r1.10 src/tests/lib/libc/gen/posix_spawn/t_spawn.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: analyzed->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 13 Mar 2025 21:35:12 +0000
State-Changed-Why:
fixed in HEAD, needs pullup-9 and pullup-10
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58091 CVS commit: src/tests/lib/libc/gen/posix_spawn
Date: Sat, 15 Mar 2025 12:09:41 +0000
Module Name: src
Committed By: riastradh
Date: Sat Mar 15 12:09:41 UTC 2025
Modified Files:
src/tests/lib/libc/gen/posix_spawn: t_spawn.c
Log Message:
t_spawn: Add missing dup2 in t_spawn_sig.
Matches what h_execsig expects, and what t_execve_sig arranges: stdin
is a pipe that the parent will write a single byte to after it has
delivered SIGTERM.
Now this should have a higher chance of provoking the bug (though it
was already good enough in cursory testing!).
PR kern/58091: after fork/execve or posix_spawn, parent kill(child,
SIGTERM) has race condition making it unreliable
To generate a diff of this commit:
cvs rdiff -u -r1.10 -r1.11 src/tests/lib/libc/gen/posix_spawn/t_spawn.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 26 Jun 2026 03:48:02 +0000
State-Changed-Why:
fixed in HEAD before netbsd-11 branch
pullup-10 #1281 https://releng.netbsd.org/cgi-bin/req-10.cgi?show=1282
needs more work for netbsd-9 to incorporate extensive changes to the
tests since the netbsd-9 branch
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58091 CVS commit: [netbsd-10] src
Date: Sat, 27 Jun 2026 17:08:21 +0000
Module Name: src
Committed By: martin
Date: Sat Jun 27 17:08:21 UTC 2026
Modified Files:
src/distrib/sets/lists/debug [netbsd-10]: mi
src/distrib/sets/lists/tests [netbsd-10]: mi
src/sys/kern [netbsd-10]: kern_sig.c
src/tests/lib/libc/gen [netbsd-10]: Makefile
src/tests/lib/libc/gen/execve [netbsd-10]: t_execve.c
src/tests/lib/libc/gen/posix_spawn [netbsd-10]: t_spawn.c
Added Files:
src/tests/lib/libc/gen [netbsd-10]: Makefile.inc h_execsig.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1282):
tests/lib/libc/gen/posix_spawn/t_spawn.c: revision 1.9
tests/lib/libc/gen/execve/t_execve.c: revision 1.3
tests/lib/libc/gen/execve/t_execve.c: revision 1.4
sys/kern/kern_sig.c: revision 1.410
tests/lib/libc/gen/Makefile.inc: revision 1.1
distrib/sets/lists/tests/mi: revision 1.1361
distrib/sets/lists/debug/mi: revision 1.469
tests/lib/libc/gen/h_execsig.c: revision 1.1
tests/lib/libc/gen/posix_spawn/t_spawn.c: revision 1.10
tests/lib/libc/gen/posix_spawn/t_spawn.c: revision 1.11
tests/lib/libc/gen/Makefile: revision 1.57
execve(2), posix_spawn(2): Add test case for an embarrassing bug.
PR kern/58091: after fork/execve or posix_spawn, parent kill(child,
SIGTERM) has race condition making it unreliable
execve(2), posix_spawn(2): Fix build of tests after previous.
Forgot to add a file.
PR kern/58091: after fork/execve or posix_spawn, parent kill(child,
SIGTERM) has race condition making it unreliable
execve(2), posix_spawn(2): Don't flush _all_ pending signals.
We need only flush those pending signals whose dispositions have been
reset to the default action when that action is to ignore them --
e.g., if the parent had a signal handler function for SIGCHLD or
SIGWINCH, this is reset to the default disposition, which is to
ignore the signal, so any pending SIGCHLD or SIGWINCH need to be
flushed.
And we have logic to do this already in execsigs(9), via
sigclearset(9), which clears the specified set of signals:
402 sigemptyset(&tset);
403 for (signo = 1; signo < NSIG; signo++) {
404 if (sigismember(&p->p_sigctx.ps_sigcatch, signo)) {
405 prop = sigprop[signo];
406 if (prop & SA_IGNORE) {
407 if ((prop & SA_CONT) == 0)
408 sigaddset(&p->p_sigctx.ps_sigignore,
409 signo);
410 sigaddset(&tset, signo);
411 }
412 SIGACTION_PS(ps, signo).sa_handler = SIG_DFL;
...
420 sigclearall(p, &tset, &kq);
https://nxr.netbsd.org/xref/src/sys/kern/kern_sig.c?r=1.409#394
But back in 2003, when ksiginfo_t was introduced, before that logic
was written, we sprouted an exithook to clear _all_ the signals (and,
more importantly for the time, free the ksiginfo_t records to avoid
leaking memory) -- and we wired it up as an _exechook_ too:
+/*
+ * free all pending ksiginfo on exit
+ */
+static void
+ksiginfo_exithook(struct proc *p, void *v)
+{
+ ksiginfo_t *ksi, *hp = p->p_sigctx.ps_siginfo;
+
+ if (hp == NULL)
+ return;
+ for (;;) {
+ pool_put(&ksiginfo_pool, ksi);
+ if ((ksi = ksi->ksi_next) == hp)
+ break;
+ }
+}
...
+ exithook_establish(ksiginfo_exithook, NULL);
+ exechook_establish(ksiginfo_exithook, NULL);
https://mail-index.netbsd.org/source-changes/2003/09/14/msg133910.html
(The first iteration of ksiginfo_exithook had another bug, of course!
But it was soon fixed; that's not the issue here.)
Later, during the newlock2 branch, sigclearall got added for execsigs
to free only the ksiginfo_t records for those signals whose
disposition is being reset to a default action of ignoring the
signal:
void
execsigs(struct proc *p)
{
...
+ sigset_t tset;
...
- for (signum = 1; signum < NSIG; signum++) {
- if (sigismember(&p->p_sigctx.ps_sigcatch, signum)) {
- prop = sigprop[signum];
+ sigemptyset(&tset);
+ for (signo = 1; signo < NSIG; signo++) {
+ if (sigismember(&p->p_sigctx.ps_sigcatch, signo)) {
+ prop = sigprop[signo];
if (prop & SA_IGNORE) {
if ((prop & SA_CONT) == 0)
sigaddset(&p->p_sigctx.ps_sigignore,
- signum);
- sigdelset(&p->p_sigctx.ps_siglist, signum);
+ signo);
+ sigaddset(&tset, signo);
...
}
+ sigclearall(p, &tset);
https://mail-index.netbsd.org/source-changes/2006/10/21/msg176390.html
And the _exithook_ was removed somewhere along the way in the
newlock2 branch (in favour of simply calling sigclearall in exit1),
but the _exechook_ remained:
-static void ksiginfo_exithook(struct proc *, void *);
+static void ksiginfo_exechook(struct proc *, void *);
...
- exithook_establish(ksiginfo_exithook, NULL);
- exechook_establish(ksiginfo_exithook, NULL);
+ exechook_establish(ksiginfo_exechook, NULL);
...
/*
- * ksiginfo_exithook:
+ * ksiginfo_exechook:
*
- * Free all pending ksiginfo entries from a process on exit.
+ * Free all pending ksiginfo entries from a process on exec.
* Additionally, drain any unused ksiginfo structures in the
* system back to the pool.
+ *
+ * XXX This should not be a hook, every process has signals.
*/
static void
-ksiginfo_exithook(struct proc *p, void *v)
+ksiginfo_exechook(struct proc *p, void *v)
{
https://mail-index.netbsd.org/source-changes/2007/02/05/msg180796.html
The symptom of this mistake is that a signal delivered _during_
execve(2) may be simply discarded, even if it should be caught and
cause the process to terminate.
On the bright side, isn't it a nice feeling when you can solve
problems by commits that consist exclusively of deletions?
PR kern/58091: after fork/execve or posix_spawn, parent kill(child,
SIGTERM) has race condition making it unreliable
t_spawn: Add missing dup2 in t_spawn_sig.
Matches what h_execsig expects, and what t_execve_sig arranges: stdin
is a pipe that the parent will write a single byte to after it has
delivered SIGTERM.
Now this should have a higher chance of provoking the bug (though it
was already good enough in cursory testing!).
PR kern/58091: after fork/execve or posix_spawn, parent kill(child,
SIGTERM) has race condition making it unreliable
To generate a diff of this commit:
cvs rdiff -u -r1.394.2.16 -r1.394.2.17 src/distrib/sets/lists/debug/mi
cvs rdiff -u -r1.1238.2.20 -r1.1238.2.21 src/distrib/sets/lists/tests/mi
cvs rdiff -u -r1.404 -r1.404.4.1 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.55.2.1 -r1.55.2.2 src/tests/lib/libc/gen/Makefile
cvs rdiff -u -r0 -r1.1.6.2 src/tests/lib/libc/gen/Makefile.inc \
src/tests/lib/libc/gen/h_execsig.c
cvs rdiff -u -r1.2 -r1.2.26.1 src/tests/lib/libc/gen/execve/t_execve.c
cvs rdiff -u -r1.8 -r1.8.2.1 src/tests/lib/libc/gen/posix_spawn/t_spawn.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sat, 27 Jun 2026 17:15:58 +0000
State-Changed-Why:
needs pullup-9 still -- change should apply cleanly but tests need a
lot more pulled up
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.49 2026/05/14 01:52:41 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home