NetBSD Problem Report #57331

From www@netbsd.org  Sat Apr  8 13:38:28 2023
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 0C4271A923A
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  8 Apr 2023 13:38:28 +0000 (UTC)
Message-Id: <20230408133826.763E11A923B@mollari.NetBSD.org>
Date: Sat,  8 Apr 2023 13:38:26 +0000 (UTC)
From: jspath55@gmail.com
Reply-To: jspath55@gmail.com
To: gnats-bugs@NetBSD.org
Subject: Automated unit test lib/libc/net/t_servent:servent fails on amd64 only
X-Send-Pr-Version: www-1.0

>Number:         57331
>Category:       lib
>Synopsis:       Automated unit test lib/libc/net/t_servent:servent fails on amd64 only
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 08 13:40:00 +0000 2023
>Last-Modified:  Sun Apr 09 06:15:01 +0000 2023
>Originator:     Jim Spath
>Release:        10.0_BETA
>Organization:
>Environment:
NetBSD nb.mach 10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Sun Feb 12 12:39:37 UTC 2023  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
Running atf tests I found service file/database errors indicating an apparent discrepancy between the /etc/services file and the /var/db/services.cdb database, on amd64 only. Other architectures do not show the same discrepancy.

Output from unit test, in part:

tps-count: 1
tp-start: 1680881450.201097, lib/libc/net/t_servent, 1
tc-start: 1680881450.201143, servent
tc-so:--- exp   2023-04-07 15:30:50.588653808 +0000
tc-so:+++ out   2023-04-07 15:30:50.803098243 +0000
tc-so:@@ -11,7 +11,7 @@
tc-so: name=3com-njack-1, port=5264, proto=udp, aliases=
tc-so: name=3com-njack-2, port=5265, proto=tcp, aliases=
tc-so: name=3com-njack-2, port=5265, proto=udp, aliases=
tc-so:-name=3com-tsmux, port=106, proto=tcp, aliases=
tc-so:+name=3com-tsmux, port=106, proto=tcp, aliases=poppass poppassd
tc-so: name=3com-tsmux, port=106, proto=udp, aliases=
tc-so: name=3com-webview, port=2339, proto=tcp, aliases=
tc-so: name=3com-webview, port=2339, proto=udp, aliases=
tc-so:@@ -26,7 +26,6 @@

[...]
tc-end: 1680881450.833599, servent, failed, Observed output does not match reference output
tp-end: 1680881450.836324, lib/libc/net/t_servent
info: time.end, Fri Apr 7 15:30:50 UTC 2023

The lines with aliases show values only in the database.

Similar errors were noted in this online report (as of 05-Apr-2023/i386 compat):
https://www.netbsd.org/~martin/amd64-compat32-atf/last_atf.html#lib_libc_net_t_servent_servent

The files are very close in time, suggesting the database was built at system install time and not modified since.

# ls -ltr /netbsd /etc/motd /etc/inetd.conf /etc/services /var/db/services.cdb 
-rwxr-xr-x  1 root  wheel  29509032 Feb 12 12:39 /netbsd
-rw-r--r--  1 root  wheel   3555799 Feb 12 12:39 /etc/services  <<<===
-rw-r--r--  1 root  wheel      4036 Feb 12 12:39 /etc/inetd.conf
-rw-r--r--  1 root  wheel    339325 Feb 15 18:09 /var/db/services.cdb  <<<===
-rw-rw-r--  1 root  wheel       255 Feb 15 19:31 /etc/motd


>How-To-Repeat:
In the /usr/tests/ directory, run:

# atf-run lib/libc/net/t_servent:servent

>Fix:
I have not fully traced the source of the services records used to create the database, but trying various dump routines indicated the alias records exist in the database only.

[Linux system commands]:
$ cat services.cdb | cdbdump | strings | grep pop
poppass
poppassd
pop2
pop2
pop3
pop3
hybrid-pop
hybrid-pop
pop3s
pop3s
kpop
winpoplanmess
winpoplanmess
cdbdump: fatal: unable to read input: truncated file
popup-reminders
popup-reminders


If the alias records are necessary, the test logic should recognize them in some way.

>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/57331: Automated unit test lib/libc/net/t_servent:servent fails on amd64 only
Date: Sat, 8 Apr 2023 14:39:53 -0000 (UTC)

 jspath55@gmail.com writes:

 >tc-so:-name=3com-tsmux, port=106, proto=tcp, aliases=
 >tc-so:+name=3com-tsmux, port=106, proto=tcp, aliases=poppass poppassd


 /var/db/services.cdb is generated from /etc/services. Unfortunately
 the entries from the source are only copied into the database, but
 old keys that aren't overwritten stay.

 If you start with a database generated from netbsd-9 and update,
 you still keep the entries from netbsd-9 that were dropped in
 netbsd-10, and the unit test will find that difference.

 Either the test needs to ignore additional entries or /etc/rc.d/sysdb
 must recreate the database from scratch (IMHO it should).

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/57331: Automated unit test lib/libc/net/t_servent:servent
 fails on amd64 only
Date: Sat, 8 Apr 2023 16:46:51 +0200

 On Sat, Apr 08, 2023 at 02:45:02PM +0000, Michael van Elst wrote:
 >  Either the test needs to ignore additional entries or /etc/rc.d/sysdb
 >  must recreate the database from scratch (IMHO it should).

 Yes (probably the easiest way forward, maybe depending on timestamps), or
 postinstall should detect the mismatch and recreate it.

 Martin

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/57331: Automated unit test lib/libc/net/t_servent:servent fails on amd64 only
Date: Sat, 8 Apr 2023 20:19:56 -0000 (UTC)

 martin@duskware.de (Martin Husemann) writes:

 > Yes (probably the easiest way forward, maybe depending on timestamps), or
 > postinstall should detect the mismatch and recreate it.

 /etc/rc.d/sysdb already checks date and "recreates" the DB. It's just
 that services_mkdb (and the other *mkdb commands probably too) do not
 remove entries.

 You can fix this in the script by not updating the db but replacing it
 with a new version.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/57331: Automated unit test lib/libc/net/t_servent:servent
 fails on amd64 only
Date: Sun, 9 Apr 2023 07:54:15 +0200

 On Sat, Apr 08, 2023 at 08:25:01PM +0000, Michael van Elst wrote:
 >  You can fix this in the script by not updating the db but replacing it
 >  with a new version.

 Actually in my case that wouldn't help, as the script is never run on
 the chroot environment - I wonder if we should add some option to
 postinstall to take care of that (e.g. by adding a special tag to the
 affected rc.d scripts and run those).

 Or i could hardcode it in my local install-sets script after it runs
 postinstall...

 Martin

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/57331: Automated unit test lib/libc/net/t_servent:servent fails on amd64 only
Date: Sun, 9 Apr 2023 06:12:30 -0000 (UTC)

 martin@duskware.de (Martin Husemann) writes:

 > On Sat, Apr 08, 2023 at 08:25:01PM +0000, Michael van Elst wrote:
 > >  You can fix this in the script by not updating the db but replacing it
 > >  with a new version.

 > Actually in my case that wouldn't help, as the script is never run on
 > the chroot environment


 The chroot either has a db that must come from somewhere, it's not part
 of a set, so something must have created but not updated it. Or it does
 not have a db and the test cannot fail then.

 So there is no differerence to a non-chroot installation. An old db existed
 and only the source file was updated.

 Making postinstall run the update commands is probably a good idea,
 then the db stays correct also without a reboot.

Home	PR Database Search