Re: WSL2
Viktor Dukhovni writes: > On Thu, Mar 11, 2021 at 07:53:20PM +, Simon Peyton Jones via ghc-devs > wrote: > >> Voila > > Thanks! > >> /etc/nsswitch.conf group entry >> group: files systemd > > The main "suspicious" thing here (decoded traces below my signature) is > that the nsswitch.conf file is configured to try "systemd" as a source > of group data, but attempts to contact "systemd" or read the underlying > systemd store directly are failing. This is different from "not found", > where systemd might have furnished a negative reply (as is the case on > my Fedora 31 system, see below). > This rings a bell. See #15230. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: WSL2
OK thanks. Let's pursue this further on this ticket:
https://gitlab.haskell.org/ghc/ghc/-/issues/19525
Simon
| -Original Message-
| From: ghc-devs On Behalf Of Viktor
| Dukhovni
| Sent: 11 March 2021 20:36
| To: ghc-devs@haskell.org
| Subject: Re: WSL2
|
| On Thu, Mar 11, 2021 at 07:53:20PM +, Simon Peyton Jones via ghc-
| devs wrote:
|
| > Voila
|
| Thanks!
|
| > /etc/nsswitch.conf group entry
| > group: files systemd
|
| The main "suspicious" thing here (decoded traces below my signature)
| is that the nsswitch.conf file is configured to try "systemd" as a
| source of group data, but attempts to contact "systemd" or read the
| underlying systemd store directly are failing. This is different from
| "not found", where systemd might have furnished a negative reply (as
| is the case on my Fedora 31 system, see below).
|
| So a failure return code is not surprising, because the answer is not
| authoritative, systemd might have answered differently if it had been
| possible to query it. It appears the WSL2 systems have a systemically
| misconfigured "nsswitch.conf" that wants to query "group" (and likely
| other) data from an unavailable source.
|
| [ Bottom line, the "unix" test case in question may need to be
| prepared
|to encounter such misconfiguration of the test platform and accept
|either type of error. Perhaps catch the IO expected IO exception,
| and
|output a fixed "not found" message regardless of the exception
| details,
|or by specifically checking for either of the two expected forms. ]
|
| By way of contrast, on my Fedora system, systemd can actually be
| reached and appears to respond to the "nss" library's satisfaction:
|
| execve("/usr/bin/getent", ["getent", "group", "xyzzy0"],
| 0x7fff3afbcca0 /* 31 vars */) = 0
| ...
| openat(AT_FDCWD, "/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) =
| 3
| openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 3
| read(3, "root:x:0:\nbin:x:1:\ndaemon:x:2:\ns"..., 4096) = 1161
| read(3, "", 4096) = 0
| ...
| openat(AT_FDCWD, "/lib64/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC)
| = 3
| access("/etc/systemd/dont-synthesize-nobody", F_OK) = -1 ENOENT
| (No such file or directory)
| socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
| connect(3, {sa_family=AF_UNIX,
| sun_path="/run/dbus/system_bus_socket"}, 30) = 0
| getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0},
| [12]) = 0
| getsockopt(3, SOL_SOCKET, SO_PEERSEC, 0x5568c64660e0, [64]) = -1
| ENOPROTOOPT (Protocol not available)
| getsockopt(3, SOL_SOCKET, SO_PEERGROUPS, 0x5568c6466130, [256->0])
| = 0
| sendmsg(3, {msg_name=NULL, msg_namelen=0,
| msg_iov=[{iov_base="\0AUTH EXTERNAL\r\nDATA\r\n", iov_len=22},
| {iov_base="NEGOTIATE_UNIX_FD\r\n", iov_len=19}, {iov_base="BEGIN\r\n",
| iov_len=7}], msg_iovlen=3, msg_controllen=0, msg_flags=0},
| MSG_DONTWAIT|MSG_NOSIGNAL) = 48
| recvmsg(3, {msg_name=NULL, msg_namelen=0,
| msg_iov=[{iov_base="DATA\r\nOK 7bc788e33c85b875f6b74a6"...,
| iov_len=256}], msg_iovlen=1, msg_controllen=0,
| msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 58
| sendmsg(3, {msg_name=NULL, msg_namelen=0,
| msg_iov=[{iov_base="l\1\0\1\0\0\0\0\1\0\0\0m\0\0\0\1\1o\0\25\0\0\0/org
| /fre"..., iov_len=128}], msg_iovlen=1, msg_controllen=0, msg_flags=0},
| MSG_DONTWAIT|MSG_NOSIGNAL) = 128
| recvmsg(3, {msg_name=NULL, msg_namelen=0,
| msg_iov=[{iov_base="l\2\1\1\16\0\0\0\377\377\377\377G\0\0\0\5\1u\0\1\0
| \0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0,
| msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
| recvmsg(3, {msg_name=NULL, msg_namelen=0,
| msg_iov=[{iov_base="\7\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0"...,
| iov_len=78}], msg_iovlen=1, msg_controllen=0,
| msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 78
| sendmsg(3, {msg_name=NULL, msg_namelen=0,
| msg_iov=[{iov_base="l\1\0\1\v\0\0\0\2\0\0\0\247\0\0\0\1\1o\0\31\0\0\0/
| org/fre"..., iov_len=184}, {iov_base="\6\0\0\0xyzzy0\0", iov_len=11}],
| msg_iovlen=2, msg_controllen=0, msg_flags=0},
| MSG_DONTWAIT|MSG_NOSIGNAL) = 195
| recvmsg(3, {msg_name=NULL, msg_namelen=0,
| msg_iov=[{iov_base="l\4\1\1\16\0\0\0\377\377\377\377\227\0\0\0\7\1s\0\
| 24\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0,
| msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
| recvmsg(3, {msg_name=NULL, msg_namelen=0,
| msg_iov=[{iov_base="org.freedesktop.DBus\0\0\0\0\6\1s\0\t\0\0\0"...,
| iov_len=1
Re: WSL2
On Thu, Mar 11, 2021 at 07:53:20PM +, Simon Peyton Jones via ghc-devs wrote:
> Voila
Thanks!
> /etc/nsswitch.conf group entry
> group: files systemd
The main "suspicious" thing here (decoded traces below my signature) is
that the nsswitch.conf file is configured to try "systemd" as a source
of group data, but attempts to contact "systemd" or read the underlying
systemd store directly are failing. This is different from "not found",
where systemd might have furnished a negative reply (as is the case on
my Fedora 31 system, see below).
So a failure return code is not surprising, because the answer is not
authoritative, systemd might have answered differently if it had been
possible to query it. It appears the WSL2 systems have a systemically
misconfigured "nsswitch.conf" that wants to query "group" (and likely
other) data from an unavailable source.
[ Bottom line, the "unix" test case in question may need to be prepared
to encounter such misconfiguration of the test platform and accept
either type of error. Perhaps catch the IO expected IO exception, and
output a fixed "not found" message regardless of the exception details,
or by specifically checking for either of the two expected forms. ]
By way of contrast, on my Fedora system, systemd can actually be reached
and appears to respond to the "nss" library's satisfaction:
execve("/usr/bin/getent", ["getent", "group", "xyzzy0"], 0x7fff3afbcca0 /*
31 vars */) = 0
...
openat(AT_FDCWD, "/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 3
read(3, "root:x:0:\nbin:x:1:\ndaemon:x:2:\ns"..., 4096) = 1161
read(3, "", 4096) = 0
...
openat(AT_FDCWD, "/lib64/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 3
access("/etc/systemd/dont-synthesize-nobody", F_OK) = -1 ENOENT (No such
file or directory)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 30)
= 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
getsockopt(3, SOL_SOCKET, SO_PEERSEC, 0x5568c64660e0, [64]) = -1
ENOPROTOOPT (Protocol not available)
getsockopt(3, SOL_SOCKET, SO_PEERGROUPS, 0x5568c6466130, [256->0]) = 0
sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0AUTH
EXTERNAL\r\nDATA\r\n", iov_len=22}, {iov_base="NEGOTIATE_UNIX_FD\r\n",
iov_len=19}, {iov_base="BEGIN\r\n", iov_len=7}], msg_iovlen=3,
msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 48
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="DATA\r\nOK
7bc788e33c85b875f6b74a6"..., iov_len=256}], msg_iovlen=1, msg_controllen=0,
msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 58
sendmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="l\1\0\1\0\0\0\0\1\0\0\0m\0\0\0\1\1o\0\25\0\0\0/org/fre"...,
iov_len=128}], msg_iovlen=1, msg_controllen=0, msg_flags=0},
MSG_DONTWAIT|MSG_NOSIGNAL) = 128
recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="l\2\1\1\16\0\0\0\377\377\377\377G\0\0\0\5\1u\0\1\0\0\0",
iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\7\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0"...,
iov_len=78}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 78
sendmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="l\1\0\1\v\0\0\0\2\0\0\0\247\0\0\0\1\1o\0\31\0\0\0/org/fre"...,
iov_len=184}, {iov_base="\6\0\0\0xyzzy0\0", iov_len=11}], msg_iovlen=2,
msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 195
recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="l\4\1\1\16\0\0\0\377\377\377\377\227\0\0\0\7\1s\0\24\0\0\0",
iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="org.freedesktop.DBus\0\0\0\0\6\1s\0\t\0\0\0"...,
iov_len=158}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 158
recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="l\3\1\1(\0\0\0\257\30\r\0m\0\0\0\5\1u\0\2\0\0\0",
iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\6\1s\0\t\0\0\0:1.303526\0\0\0\0\0\0\0\4\1s\0*\0\0\0"...,
iov_len=144}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 144
close(3)= 0
--
Viktor.
So group lookups are configured to try /etc/group first, and then some
systemd-based machinery (possibly creating groups on the fly, ...).
> == Tracing getent group xyzzy0
execve("/usr/bin/getent",
RE: WSL2
@haskell.org | Subject: Re: WSL2 | | On Thu, Mar 11, 2021 at 12:21:15PM +, Simon Peyton Jones via ghc- | devs wrote: | | > Like Tom, I'm not following the details, but if you want me to run | > some commands and send you the output I can do that. Just send the | > script! | | See attached. If any of the prerequisite shell utilities are not | installed, the script will exit asking that they be installed. | | Please email me the output, or post to the list. (Should be just a | couple of hundred lines of mostly hex output). | | -- | Viktor. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: WSL2
On Thu, Mar 11, 2021 at 12:21:15PM +, Simon Peyton Jones via ghc-devs wrote: > Like Tom, I'm not following the details, but if you want me to run > some commands and send you the output I can do that. Just send the > script! See attached. If any of the prerequisite shell utilities are not installed, the script will exit asking that they be installed. Please email me the output, or post to the list. (Should be just a couple of hundred lines of mostly hex output). -- Viktor. getgrnam.sh Description: Bourne shell script ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: WSL2
PS: since this is not, apparently, just my stupidity, it would be good to open
a ticket and transfer this thread to it. Would someone like to do that?
| -Original Message-
| From: ghc-devs On Behalf Of Tom Ellis
| Sent: 11 March 2021 11:41
| To: ghc-devs@haskell.org
| Subject: Re: WSL2
|
| On Thu, Mar 11, 2021 at 06:19:46AM -0500, Viktor Dukhovni wrote:
| > On Thu, Mar 11, 2021 at 06:05:04AM -0500, Viktor Dukhovni wrote:
| > > So the question is why the lookup is failing. To that end
| compiling
| > > a tracing with "strace" the below C program should tell the story:
| [...]
| > To experiment with other group names and make sure that at least
| group
| > "root" or similar works, a slightly extended version is:
| [...]
|
| I'm not really following the details, but is this useful to you?
|
| % cat g.c && cc g.c -o g && ./g
| #include
| #include
| #include
| #include
|
| int main(int argc, char **argv)
| {
| char buf[1024];
| struct group g, *p;
| int rc;
|
| errno = 0;
| rc = getgrnam_r(argc > 1 ? argv[1] : "nosuchgrouphere",
| , buf, sizeof(buf), );
| printf("%s(%p) %m(%d)\n", p ? g.gr_name : NULL, p, errno);
| return (rc == 0 && p == NULL);
| }
| (null)((nil)) No such process(3)
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
| haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devsdata=04%7C01%7Csimonpj%40microsoft.com%7C48a10ad0766c4dd6caf4
| 08d8e4829c7d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637510597246
| 441070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
| BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=nQdF9H7BpTqQL%2Bm0URWQmXh
| 1KEQAV1KgfPvG75mOR%2B0%3Dreserved=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: WSL2
Like Tom, I'm not following the details, but if you want me to run some
commands and send you the output I can do that. Just send the script!
| -Original Message-
| From: ghc-devs On Behalf Of Tom Ellis
| Sent: 11 March 2021 11:41
| To: ghc-devs@haskell.org
| Subject: Re: WSL2
|
| On Thu, Mar 11, 2021 at 06:19:46AM -0500, Viktor Dukhovni wrote:
| > On Thu, Mar 11, 2021 at 06:05:04AM -0500, Viktor Dukhovni wrote:
| > > So the question is why the lookup is failing. To that end
| compiling
| > > a tracing with "strace" the below C program should tell the story:
| [...]
| > To experiment with other group names and make sure that at least
| group
| > "root" or similar works, a slightly extended version is:
| [...]
|
| I'm not really following the details, but is this useful to you?
|
| % cat g.c && cc g.c -o g && ./g
| #include
| #include
| #include
| #include
|
| int main(int argc, char **argv)
| {
| char buf[1024];
| struct group g, *p;
| int rc;
|
| errno = 0;
| rc = getgrnam_r(argc > 1 ? argv[1] : "nosuchgrouphere",
| , buf, sizeof(buf), );
| printf("%s(%p) %m(%d)\n", p ? g.gr_name : NULL, p, errno);
| return (rc == 0 && p == NULL);
| }
| (null)((nil)) No such process(3)
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
| haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devsdata=04%7C01%7Csimonpj%40microsoft.com%7C48a10ad0766c4dd6caf4
| 08d8e4829c7d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637510597246
| 441070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
| BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=nQdF9H7BpTqQL%2Bm0URWQmXh
| 1KEQAV1KgfPvG75mOR%2B0%3Dreserved=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: WSL2
> On Mar 11, 2021, at 9:41 AM, Tom Ellis
> wrote:
>
> I'm not really following the details, but is this useful to you?
>
> % cat g.c && cc g.c -o g && ./g
> #include
> #include
> #include
> #include
>
> int main(int argc, char **argv)
> {
>char buf[1024];
>struct group g, *p;
>int rc;
>
>errno = 0;
>rc = getgrnam_r(argc > 1 ? argv[1] : "nosuchgrouphere",
>, buf, sizeof(buf), );
>printf("%s(%p) %m(%d)\n", p ? g.gr_name : NULL, p, errno);
>return (rc == 0 && p == NULL);
> }
> (null)((nil)) No such process(3)
Yes, it means that the reported error is not an artefact of
the Haskell "unix" package, but rather originates directly
from normal use of the getpwnam_r(3) glibc API on these
systems.
It would now be useful to also post:
- The output of "./g root" or some other group known to exist.
- The output of "./g xyzzy" or some other short group name known to
not exist
- The output of "grep group /etc/nsswitch.conf"
- Attach an strace output file (g.trace.txt) from:
strace -o g.trace.txt ./g
--
Viktor.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: WSL2
On Thu, Mar 11, 2021 at 06:19:46AM -0500, Viktor Dukhovni wrote:
> On Thu, Mar 11, 2021 at 06:05:04AM -0500, Viktor Dukhovni wrote:
> > So the question is why the lookup is failing. To that end compiling a
> > tracing with "strace" the below C program should tell the story:
[...]
> To experiment with other group names and make sure that at least
> group "root" or similar works, a slightly extended version is:
[...]
I'm not really following the details, but is this useful to you?
% cat g.c && cc g.c -o g && ./g
#include
#include
#include
#include
int main(int argc, char **argv)
{
char buf[1024];
struct group g, *p;
int rc;
errno = 0;
rc = getgrnam_r(argc > 1 ? argv[1] : "nosuchgrouphere",
, buf, sizeof(buf), );
printf("%s(%p) %m(%d)\n", p ? g.gr_name : NULL, p, errno);
return (rc == 0 && p == NULL);
}
(null)((nil)) No such process(3)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: WSL2
On Thu, Mar 11, 2021 at 06:05:04AM -0500, Viktor Dukhovni wrote:
> So the question is why the lookup is failing. To that end compiling a
> tracing with "strace" the below C program should tell the story:
>
> #include
> #include
> #include
> #include
>
> int main(int argc, char **argv)
> {
> struct group g, *p;
> char buf[1024];
> int rc;
>
> errno = 0;
> rc = getgrnam_r("nosuchgrouphere", , buf, sizeof(buf), );
> printf("%p: %m(%d)\n", p, errno);
> return (rc == 0 && p == NULL);
> }
To experiment with other group names and make sure that at least
group "root" or similar works, a slightly extended version is:
#include
#include
#include
#include
int main(int argc, char **argv)
{
char buf[1024];
struct group g, *p;
int rc;
errno = 0;
rc = getgrnam_r(argc > 1 ? argv[1] : "nosuchgrouphere",
, buf, sizeof(buf), );
printf("%s(%p) %m(%d)\n", p ? g.gr_name : NULL, p, errno);
return (rc == 0 && p == NULL);
}
This gives (again Fedora 31) the expected results:
$ make g
cc g.c -o g
$ ./g
(null)((nil)) Success(0)
$ ./g root
root(0x7ffe6a6225d0) Success(0)
--
Viktor.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: WSL2
On Thu, Mar 11, 2021 at 10:19:52AM +, Tom Ellis wrote:
> SPJ Wrote:
> > I've just installed WSL2 and built GHC. I get this (single)
> > validation failure in libraries/unix/tests/getGroupEntryForName. It
> > seems to be just an error message wibble, but I can't push a change
> > to master because that'll affect everyone else.
>
> Interesting, I've only ever built GHC on WSL and WSL2. I've seen this
> error message on WSL2 during every test run, I think. I didn't
> realise that it never occurred on other platforms, let alone that it
> was WSL2 specific!
I am curious what specific version/branch of GHC (and associated
submodule commit of "unix") is being tested.
I've recently cleaned a bunch of the upstream "unix" handling of the
group/passwd database handling, but I don't believe that GHC has yet
switched to the newer code.
A subtle facet of the delta points in the right direction:
-getGroupEntryForName: getGroupEntryForName: does not exist (no such group)
+getGroupEntryForName: getGroupEntryForName: does not exist (No such
process)
not only is it complaining about "process" rather than "group", but
crucially the case of the word "No" is different. The variance is due
to the fact that there are two possible error paths with group lookup
in the group lookup code:
doubleAllocWhileERANGE loc enttype initlen unpack action =
alloca $ go initlen
where
go len res = do
r <- allocaBytes len $ \buf -> do
rc <- action buf (fromIntegral len) res
if rc /= 0
--hard-error-> then return (Left rc)
else do p <- peek res
--not-found--> when (p == nullPtr) $ notFoundErr
fmap Right (unpack p)
case r of
Right x -> return x
Left rc | Errno rc == eRANGE ->
-- ERANGE means this is not an error
-- we just have to try again with a larger buffer
go (2 * len) res
Left rc ->
--1--> ioError (errnoToIOError loc (Errno rc) Nothing Nothing)
notFoundErr =
--2--> ioError $ flip ioeSetErrorString ("no such " ++ enttype)
$ mkIOError doesNotExistErrorType loc Nothing Nothing
The expected error path is "not-found" -> (2), where the group lookup
works, but no result is found (rc == 0). This reports the lower-case
"no such group".
The unexpected error path is a non-zero return from "getgrnam_r"
(action) -> (1), which uses `errno` to build the error string, which
ends up being "No such process".
On Linux systems that's: ESRCH 3 /* No such process */
So the call to "getgrnam_r" failed by returning ESRCH, rather than 0.
The Linux manpage does not suggest to me that one might expect a
non-zero return from getgrnam_r(3) just from a missing entry in the
group file:
RETURN VALUE
The getgrnam() and getgrgid() functions return a pointer to a
group structure, or NULL if the matching entry is not found
or an error occurs. If an error occurs, errno is set
appropriately. If one wants to check errno after the call,
it should be set to zero before the call.
The return value may point to a static area, and may be
overwritten by subsequent calls to getgrent(3), getgrgid(),
or getgrnam(). (Do not pass the returned pointer to
free(3).)
On success, getgrnam_r() and getgrgid_r() return zero, and
---> set *result to grp. If no matching group record was found,
---> these functions return 0 and store NULL in *result. In case
---> of error, an error number is returned, and NULL is stored in
---> *result.
ERRORS
0 or ENOENT or ESRCH or EBADF or EPERM or ...
The given name or gid was not found.
EINTR A signal was caught; see signal(7).
EIOI/O error.
EMFILE The per-process limit on the number of open file descriptors
has been reached.
ENFILE The system-wide limit on the total number of open files has
been reached.
ENOMEM Insufficient memory to allocate group structure.
ERANGE Insufficient buffer space supplied.
The "0 or ENOENT or ESRCH ..." text then plausibly applies to
getgrnam(3), and its legacy behaviour.
So the question is why the lookup is failing. To that end compiling a
tracing with "strace" the below C program should tell the story:
#include
#include
#include
#include
int main(int argc, char **argv)
{
struct group g, *p;
char buf[1024];
int rc;
errno = 0;
rc = getgrnam_r("nosuchgrouphere", , buf, sizeof(buf), );
printf("%p: %m(%d)\n", p, errno);
return (rc == 0 && p == NULL);
}
On a Fedora 31 system I get:
$ make g
cc g.c -o g
$ ./g
(nil): Success(0)
If something
Re: WSL2
SPJ Wrote: > I've just installed WSL2 and built GHC. I get this (single) > validation failure in libraries/unix/tests/getGroupEntryForName. It > seems to be just an error message wibble, but I can't push a change > to master because that'll affect everyone else. Interesting, I've only ever built GHC on WSL and WSL2. I've seen this error message on WSL2 during every test run, I think. I didn't realise that it never occurred on other platforms, let alone that it was WSL2 specific! Tom ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: WSL2
| Hmm, this is quite unfortunate. My recollection is that WSL2 by | default runs an Ubuntu image, so I'm somewhat surprised that this is | failing. bash$ uname -a Linux MSRC-3645512 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux bash$ cat /etc/os-release NAME="Ubuntu" VERSION="20.04.2 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.2 LTS" VERSION_ID="20.04" HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; VERSION_CODENAME=focal UBUNTU_CODENAME=focal | -Original Message- | From: Ben Gamari | Sent: 10 March 2021 17:22 | To: Simon Peyton Jones ; ghc-devs | Subject: Re: WSL2 | | Simon Peyton Jones via ghc-devs writes: | | > Friends | > I've just installed WSL2 and built GHC. | > I get this (single) validation failure in | > libraries/unix/tests/getGroupEntryForName. It seems to be just an | > error message wibble, but I can't push a change to master because | > that'll affect everyone else. | | Hmm, this is quite unfortunate. My recollection is that WSL2 by | default runs an Ubuntu image, so I'm somewhat surprised that this is | failing. | | Can you paste the output of `uname -a` and `cat /etc/os-release`? | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: WSL2
Simon Peyton Jones via ghc-devs writes: > Friends > I've just installed WSL2 and built GHC. > I get this (single) validation failure in > libraries/unix/tests/getGroupEntryForName. It seems to be just an > error message wibble, but I can't push a change to master because > that'll affect everyone else. Hmm, this is quite unfortunate. My recollection is that WSL2 by default runs an Ubuntu image, so I'm somewhat surprised that this is failing. Can you paste the output of `uname -a` and `cat /etc/os-release`? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
