Re: WSL2

newer
Inlining of `any @[]` vs `elem...

older
What type of performance...

Tom Ellis

11 Mar 2021 11 Mar '21

5:19 a.m.

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

Show replies by date

Viktor Dukhovni

11 Mar 11 Mar

6:05 a.m.

New subject: WSL2

On Thu, Mar 11, 2021 at 10:19:52AM +0000, 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). EIO I/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", &g, buf, sizeof(buf), &p); 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 else happens on WSL2, running $ strace -o g.trace ./g may reveal something not going right during the lookup if the problem is with some system call. On the other hand, if the problem is entirely in "user-land", then it may take more work to see what's going on. Is group database on these systems backed just by local files or by AD LDAP? A look at at the "group" entry in /etc/nsswitch.conf may shed some light on how groups are found. -- Viktor.

Viktor Dukhovni

6:19 a.m.

New subject: 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", &g, buf, sizeof(buf), &p); 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", &g, buf, sizeof(buf), &p); 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.

Tom Ellis

6:41 a.m.

New subject: 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", &g, buf, sizeof(buf), &p); printf("%s(%p) %m(%d)\n", p ? g.gr_name : NULL, p, errno); return (rc == 0 && p == NULL); } (null)((nil)) No such process(3)

Viktor Dukhovni

7:04 a.m.

New subject: 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", &g, buf, sizeof(buf), &p); 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.

Simon Peyton Jones

7:21 a.m.

New subject: 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", | &g, buf, sizeof(buf), &p); | 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- | devs&data=04%7C01%7Csimonpj%40microsoft.com%7C48a10ad0766c4dd6caf4 | 08d8e4829c7d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637510597246 | 441070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ | BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nQdF9H7BpTqQL%2Bm0URWQmXh | 1KEQAV1KgfPvG75mOR%2B0%3D&reserved=0

Viktor Dukhovni

2:04 p.m.

New subject: WSL2

On Thu, Mar 11, 2021 at 12:21:15PM +0000, 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.

Simon Peyton Jones

2:53 p.m.

New subject: WSL2

Voila simonpj@MSRC-3645512:~$ sh /mnt/c/tmp/getgrnam.sh /etc/nsswitch.conf group entry group: files systemd == Tracing getent group xyzzy0 1f8b080818754a60000374726163652e6f757400ed5a6d73daba12fe9e5fa1e1cc9d212d09b6e4 373ac3e9e182493c0593b14ddb4ce9788c2d12a6bc5ddbe4909ef4bfdf950d040c26b831bdf743 9336962d69779fd56a575a892ea8fb408b85f23cf0cbfde1a47c47433a090b25f4a5b02e16eefc e97cc60a8bc7efdf1fb9c2d712e216f26040fb6265203b8443e537084be8c1f103f4a67c8eaa88 3bebfbdf8a7ab7d53a47877fa0ed4214dd3e2f7b3c073f678eefdedb33df0d47456e41388e67d4 6b46fdda7efffe3d905f32773941ea2b32cf3176173c5235fd63ad858adae4c1190d3de4f877f3 3100383f735c97060180a4a15b1e7997c1f472e6d3d1d4f1009361773e9caf246164f48eaa5ba8 a84f513077efd16038a268ea236fe853379cfa8fe767d3199d3861b166d9cd46fd5303f4b241d9 75dc7b0a743bb6d1e8e8addba78e5d6f75d4cf6a9dc949ce0641087d4909fd1384f678ead1aa69 6b4d43bd7ae224412821f81a0cbfd32a11154529a1cbcbcb1fb13ec763671629b48496753746c7 b20db50612b46b37f68da17dac592a548386a23ea026ecf62587ef33bdbaa369408be4a5f18898 ed81381af6cb0b45b225e162349ccc1717779339fbe832d4d201c43e753c06b8d0e365596d357b b8c7c32fe971895ff8f2273cf8d5abc4fd07daaeeb0ba08b1252086664e1713663942521a62d2d 9b09f1f3af6dda875f63cab202ea9704461d8adbd497547b78d5478c9f577a977d8de5e5d6dc93 e0403b0483ec8212a904a7104ff48e89873d4c480f63fcaf1e96851e96a01ec420a041f61f4b3d 9ec90535b2f4f94fa827311c092c4451224390944366278be2b3d9610e573016520c4fe12b78c3 ee9ea2d227436356b761824fac5cd33bfa6dbbd3354b30ad762cb2c22cf2f7001e3f801ba38039 2255449ce60022ed3754fd7639304977a06099297f3cf3a721b8b4e2fabbe0c2f712e21541c615 69491e4651ddb0839dc6a2c071ebc6cf46c1a6ffae544dedb3dad827df028b406e4bca88c136d3 8a2b444c0947784e38883f9d135ff112ac62b2dbac1c6e10b1c28228efa24b31f9034ca99c601a 334830e5c558a944c44a76a687679c9835066cc4e128fa9a2a4403b3b441d21163f3dc634c2bfd f1186f85aa9de671e87758e487e6c2b62da51117f903ade7936d9df6639b6131f33c01f1a7d728 ace3fa13e1a3b17da163d46a5f60654b2f165c4753d719d1e5e382697ff890cb4a822362e42ef6 af2556b5c7ae264481cf6135c14007f78e4fb7615fc2d2cd0972008d2bcc349e11af17217fa056 c4094d9c3145113be439a183fa4e402f7b933f62e7cb4c8bf564749e3b175615e95873d0cb8631 d42fbb56f34229b7eab6063ec5d29a5abd66691d3d0f15a5da04ce620f8ec8e5640f7b579877ee 74f210ffbd0030f3110d76d6d81971832b4e451ed725b09bd735436dec5b587b3942df1df2b65a 33bb86da8681cf63bc491a6892652fe19e14b2a5b6d49b6b5873e40058905300b38a5fbb794a07 5c6b340cd5347380cb133e056f5473bc7fcf733eef02d66bed3c06574a9bc2529658460627c57a 53bb518d3c4278da868ca4ae82f781a527f656a659bb52b39b72433312bbd07861f78cf8e43297 cd5bd37e0d863dde272d7b236448dd88e4c411063cad55336ef3082f32971e54b3203e6d80a977 5a2d609c87bf157985e7d340af6b8f054edcca6923ab968bdf25444a831c571d8f57396d9ce9b6 5543abe700594c032c66822b9fd6aeaddb9b3cc617733c965397c7cbcaa3415732671d82a9fb8d 02e8a6ddd5b5cf256476ea1f6cd30266eda7a8bc4415bfe81dfddf2d282cf99233d8274c58aa20 02ead803673c1c3d56d7d482f9c49e39e17db5507e70fcb23f9f942781eb9563ae851f306f9f0f 145e3e09f80d6cbf99b2e3904910fc3d0cddfb4b907c90c72cdc76b51b1bfa5d76b08d877f485d 38e3d9886eefe881ceafdcd0ff5f9f0c11258f609b763204436233db0a187a9cfd8428793eb47b 42c471e2ee31c0c609d1f1b6a590349f2757a47497f752ae9dc8ca4e9697c87146122bdb847f2e 714e1279e5987a82a382238e89e39b2c6c9c249b8864928db08fcd4fa6ccfb3b1c77b3f4449162 55629277c23c269d696aece4a9570a39264f1d4fc5943c758a5f599dcba7cdab5140e93766fe40 d7545508315d631f12c6e2d8a9a26065af1bf6a7d3f0dde21df7ae37f11c3a9e4ee0858797fe90 953094826d3f0c843208c85afff6dabfca6b078f4148c7dea9fc36b88e692e7e1b938ab29d29d8 5cac0a024fa49ff6dc64f7fc91087879e8294ac2aebfc9eabaa5a48713f6f85449895d48857fe1 c4f7c0d9aa9b6424ed8b4ab1afe299d77abdf726c9f3ce98fea98c7616de33636406cb9dc26031 335afea0cd66b8114004f1cae91149ee6149b4e2db00b200cb19fee3f9ede02bb0233d42e48d6b 0058c8788f8317e5c4358e5f23df660644e0042ed5adbd38ffe22b22db368ae35362a92291d7af 9c762c34a29ee048e29366cc094aea66ffa5b37f25c9283e0a4e3092725c3bf13b333e229f64a9 2c6f1b087bb4f9bac513c99cdbd95d3c2d3572dc9580b5fbda7bdf20a0a11d0e3ddbf13c9f5d05 dcb8c2a0881b47f755e82f0b246aef4ffb73984da361106eb597a25b21e76bc17d36e3ee1c371c 4e274553bb32acb6a6c79bf47b67e28da85fddb0b0fe00ba43d5d809be55bf7c8dca8391731754 cd1a086c5a1d43359ea00c9434bdd9891a80ccb02ddf2244213cc1a67e792deb3c45129b4f15c4 ad1c29082bd70ceb5532c168b98c1193caeeae321b5f22552126e6d744b7993f1a8e8721b82b90 d268696dcdb2410cd62b6ef70f6b60bb73bf5a9115e50dcf3167177d1b3b8b2aeb21093608abe9 9a75fb23fb8a7b8fdc2ba9afbb37a86b1a3cfb83d18d76a3a25acb68a3fa75ab812cd3825ae30a 7db4a28f60884df449d3ebd748eb004aa6e925c63b1a824d168f981d4ba3dc97406a5c1989fc51 e68cd15f8579407daf7fc14b7d85488e57c1dcc0237deaf032e5078ec0d1ca000f88cbb248025e 2591ea1d5d37d466d7541ba8588f7981e1219f0e809ef7ea1c124b612dd7a1e558c0f276645fa5 c89e833c941a9aa1d6c1766f8fcf75fd2f79ef313353b5da35f3436c2a5b93822e86a11dedf98a f89056abe8fdd9dbb76f116b4f3df4f730bc4718c197b3ff02e18adc56ef2d0000 == Tracing getgrnam xyzzy0 (null)((nil)) No such process(3) 1f8b080818754a60000374726163652e6f757400ed597d6fda4813ff9f4fb1a27a24686958effa b512d7e3c049ac12880cb48d4a65197b49ac189bb34d4b7ae9777f666da0600309497b8ff4dc35 4dbdde9dfdcdececbc79ca16ccf9c22ae593fa354baea3c09e966be8d3f66b7971f7eddb1d2e7f ae21bc502693892ab88ee05015d55f2222a32f7614a397f52a6a205c1a47b795eeb0d3a9a2c37f 807621c9a22660577131c6253b726eac59e4247e052f28c602476f9aad73ebeddbb700bf623eb6 6d9b0a63ccd9bd16906e74df373ba862045f6cdf73911d5dcfa72c48aa25db71581c57ca759638 75df3d89c39359c4fcd076e14ca6d57b575d49c261ba3dbd3b40956e88e2b97383269ecf501821 d78b989384d15db514ce58602795e6c03a6db73eb4412f1bc88eeddc30c0ed5966bbd7ed5cddf7 ac56a7a77fd45b5c4e5a9ac409eca535f4579c58d3d0658dbe659c9afad93d9645b1866036f6be b106955455ada1939393ef993ea7537b962ab486966b97666f60997a1324b8685e5a97a6f1be39 d061193494ee0135b9984e983ae17a75fc306615fad07da4cc761cd1f7c6f5852a5bb2f8daf782 f9e2f57530e7930e3fb57ce0c411b35d7ee0f2485014bd733a2223017ee808e77e60e6377808ab 5719ff09b4ebf532e8a286544a382c3c4a338e2c8b19b6bc2413b3e7efdbd8875f33644505f5cb 224787e136fa127544567ba4ec79d61df2d94c5ebce69e3f1c688712905d545395903de0b9dd19 783222948e0821ff1911451c1119d6410c0a1ae4bf441e095c2e5851e48fbfc13acd8e238385a8 6a6a08b27ac8ec1449fa617604138d10718fe1a9824636ecee3e1d7d300d6e751b2678cfc7cd6e af7b75d11bf66be056058b4c3dfddf0b7cfc056edc02c154d624b22f00a4da6febddabe5c5e4c3 81a38db9f2a7b3284c20a455d6f30e4ce31a125451219abc84875bd437eca0402c8918af897f18 0577ffa254a7c647bdbd4bbe0591006e4bca94c1365346d59429c554c0e2c1f3efe724686e8e55 069b63a5d294151125a578ba3d267f802953f24c530679a65aa6542a11f578a6873d4e3b36076c e4e134fbf675c806fdda062483cb5fda46de9856fa1308d94a5505729efaf1c4959d945cdcb6a5 7de08e74807a1e6ceb7492d90ccf99d5dc11e3d0b96590e64ead61d7f85843fd5eeb9dd51f00d8 c57d3a5e26b2ec05d4fb4707064bd5d292130601972b0dabb635b1a79e7fd758a3c5f3c09ad9c9 4da35c87caa81ecd837a103b6e3de35afe0eda11d6d5cbc365c73177f77f7bb02757957ce37a4a 63a9373eb031a5da57ed0571fcd54b9c9b13d0d5e427d47b92803793eeba687a818aec46c10bf8 8bf4853d9df92ccb16dc17f856c0f9b1b9bc9adfafd0675685ffe0c217aec4e2d61cf3d393e30b e07cf95b2c8031968a55ce4601fc78db5279f5b253a58a262b4f2f2554a590c41cd5ce32a7ba0d fcb4ba80e6cb82143dc7119c9573cc55a7c7b0b1f36c52c83c1bba8bcd132b82718163b11e70b4 2ccf11427f763d90411fe51ac58271a99067a7e13d71e53a0ae7b3037ee5c78cdd72f307dcbeae 43521b9abb4ec2593cd65554a2ee0cc35118266f166ff09b51e0da6c1a06f022c0cbd8e32302a3 783b0e03d0110272ea7fa3f6df15b5e3bb386153f757c56d8271f853e236a19aca5d6ba7568928 0a547e72e416c7c5702309cb6f3a28808af1e6d8d02de7239cb423a62a4a164234e1810fda039f 8e4e9e91b22b2b2dbf4764aa8acf8fde34ff3997e1ff2aa39d2537dc18b9c1e25f61b0841bad70 d0668f687850513ab34754564644960659b34311a19c11de57af269f811d1d51aa6c7439887864 9b4a90945c97eaef916fc3ff04118b786f587bd0ff48b1e7e0902c47ca9a4c9f5f39152c3445cf 7114b32e0ec1a28a9fda4f51f38cc462e7c611a59f583b09058f4fe1f32c95653345dca1cde715 4f29f4338b27f1500fa3407db09d12b3c44a3cd7b25d37e2ffd3b1d1a151858defdc06ec57442d a58fc2f11cbcc9f7e2648b9ea44dafea5af0887bdcb5ed245e1854fac69939b830ba595be0c60e 5c9f458d0d0b1b4f603b2c4dedf8b6f1e9733a9ef8f675dce83741e0fea067eae63d8c01c9e89e f65202903909a34d20ea52077fafa165d7b9ba47124bd82b88a33d52103e6e9a8367c904b7e570 465c2a6bb8eaa57c4a5585b8989f73db6691ef4dbd04c2154869768c0b636081187c5746f71727 b09c79d4d014557d29601eecd2b9a9bd68f01db26881b046d7185c7d3fbee2de21f74aeaf3e125 1af64d81ff43d0a571a9a366c7bc40adf34e1b0dfa035835cfd0fb413a0986788a3e18ddd63932 7a704aaee9e519af590236597984772c8d7257cbaa7d66e63a5647f7a87e2fcf6316b9e3d7c461 8e0b8e3ba60cd2b7643b92cc404532241647d26c8df7ad44b26a5bb57addaea99f0efb7a1b555a 192f303c14b109e0b9c775ad76a47ade345bd6a1f54cc0fa76665f35e57e247918b50d536f81ed 5e3dbebbf6bfe4bdc3ccfafae0a2d97f9799ca965364b95fc8e5fed6b90955318f4a301bb9ec4b 636adf327882a1f35088176275b30ef81a7909e328e54a30f7fd6aa512787eb58a56527261788c a4d52cbf539a9a132db1859758e92767654f6b70759f6f4baf5ebd429c9eb9e8ab97dc208c60a6 f45f7443942f431f0000 == Tracing getent group root root:x:0: 1f8b080818754a60000374726163652e6f757400ed5a6d73da3810feceafd0d0b919d2129025bf d199b4c781d330259031d02673dc7884110913b039dba4f42efdefb7b281808d29f44ce73e5c08 b1ac97dd7d56ab5d6915bee0f6132fe4cb73df2b0fc64ef99e07dc09f245f47b7e5dccdf7bee7c 260a9eeb06f93f8a082fb4d188332c8d46f208a3f26b4454f4c43c1fbd2e9fa10b847303efb1d0 ea359b6768ff0ff45d282a1d60a922318c718e79f68335f3ec6052c00b8ab124a857cdda95f5fe fd7b20bf646e6bba32a2ba8a05bb7309198dd6a76a13151ace139b8c878879f7f329887f9663b6 cd7d1f20f2c02e4f8625df2dcd3c3e71d910109956fbe3d94a1241a6d5365a5d5468b9c89fdb0f 68349e70e47a6838f6b81db8ded7b39c3be30e0b0ad5ae7559af7dae83563628dbcc7ee040b76d 99f576ab79f7dcb66acdb6716bd4849c3437f203184b8be86f3fb0a6ee905f74acc6a5697c78c6 aa2c1711d4fae3bff80555745d2fa252a9f42dd2e774ca66a1428b68d97663b6bb9669544182eb ea8d7563363e55bb06348386c231a026aeea1ab635a1577be2fabc40bf371f21b31d1027e34179 a1ab962a9f4fc6ce7c717eefcc45a52d50ab7b107b9c0d05e07c5fd234a379d9277d093eb48f63 1fa879070f69f5aae23fa1efba3d0fba28229d1241161eb999a0acca116d75d94d8e9ebf6ed3de ff1a51d67450bf2a0bea50dca6bea4da27ab314af4fcd0ea89da485ebce61e0707daa1046497f5 50252485786c74443ce8134afb84905ffa4493fb44857610838206c597a87d49c8052d9a7afb0e da690447050bd1f5d010547d9fd9698af2627604930a21728ae1e952856cd8dd7358fa6c3684d5 6d98e0b328575bedd6dd75bbd729c2b24a58a4222cf2ff093c7c0237668160aa561492e60042ed d78dd6dd726262ee40e5432a943f9d796e002eadb0ae1fe9505f44922e6ba4a22ec9c32c1a1b76 90e8acc818af3bbf188558fe49a92e1bb7467d977c0b220c624bca90c116530d0b3f064c29a612 96f7e24fe7245586dbac966463ac0683901591152d892ec5e4f730e55a9c69c820c6d49622a552 85e8c733ddbfe2a46363c0461c0ea36fc78068d0296e905495c83c93c6b4d69f44c856a84a740f 433faed061d85ddeb6a534e2a37dbde7ceb64eb5c86644cc3c8b41fce13d8a18b8ae1200f06e12 1b03c35ebb02abd87889e03a716d36e1cbc7b9d0fef829939d04a64ae82e76ef2556ad07ee26d4 011f66b09b10a0fd07e6f16dd825d8ba313f03d0a4224ce305f17a13f20a35434ec861538e4276 68c8028606cce7a5bef32a72bec2b4c44841e765707ed5908e3503bd6c1843add4eb5e9eebe566 cd6a804fe9362e1bb56ab7d16e65a1a2549b2047d8032c463b237bd8b9c3bcb75de729fa7b0e60 e613ee27f6d847e20687908a3c6a8b61ef5c554da3be6b635dc9107a72caaf8d6aa7671ad730f1 59cc374d034d8f394be82785dc359ac6cd15ec3932002c6b298045c3cf3d3ca503aed6eba6d1e9 640057a2520adeb0e570ff9ee57a4e026e55afb3985c356d09ab47c5b2c149b1de546f0c338b10 9e7620a3a9bbe05d60d989bd55a753fd601c6fcaf586193b85461bbb17c42797b9dcb9eb58ff06 c30eef9396bd910f4fddc09c9d38c280a7ed56cdbb2cc28b86d383ea31884f1b606aed66131867 e16f154997a434d0ebd64381334d396d646d64e2772955d320474d87e3954f1b677ad786d9a865 00594903ac1c05979ed6aebb773759cc2fc112d152b7c7cbc68341cb47671d7cd77ee400fad2ea b51ab745d469d73e5a9d2e30bb7e0ecb4b54d14babddfaad0985255f9a8373822352052150668d d8743cf97ab1a6e6cf1d6bc682878b7cf98979656fee941ddf1e9623aef96fb06ea5f585c2f76f 02fe07b6db4cc57588e3fb5fc681fd5002c94759acc26d57bb71a04fb283633cfc2263c1a6b309 df3ed1039d9f79a0ff2fdf0ca98c66116cd36e86604a2c615bbe404f8ebf218adf0f256f883056 92d7001b374487db964ed37c9e5651d35ddef772ed8cc8f12c2fd4451949a26f13feb1c4398de5 cd23ea718e3ce418bbbe39860d4bb0e1493614ef62f38329f3419c234d64e9a18e44aa2434e384 f992f4514b2371a3b252c80179eae5524cc953a7f895d5ad7cdaba9af89c3f0af307ba1dc38010 d3337721112c0e5d2a3ad177ba61f18f016f176ff1dbbe33647cea3af022c1cb602c4a044afeb6 1f064247693712508a0958bb82b3a34a7028a037e44f1753f6c8e1098a159e102fe4b34d79bf78 e3800b2a9b02830aa55802ff026a727c310eac50c98594fcfeaaf3fbdc9b376f90e8cf8708e2d0 03c2086a72ff00018c8ab25e210000 == Tracing getgrnam root root(0x7ffc07bd1490) Success(0) 1f8b080818754a60000374726163652e6f757400ed586d73da3810feceafd0d0b9196808c892df c80ccd71c4699912c840d2a673bef1185b4e9880cdd926a577e97fbf956c88b18184b49fee2e84 b12c4bcfee3e5a691fcc96cc79609572bd71cbe2dbd0b767e51afa7df3b61c06415cfea386f052 f33ca6784a932a4d1d35de22a2a2073b8cd0db4615b5102e8dc3fb4affbad7aba2fd7f3076a928 ae3a1e2b2ac31897ecd0b9b3e6a1134f2b78493196387a7bd8f9609d9e9e027c6adcc1dad89574 86b9b9630919ddfea7760f55bafe833d9db8c80e6f1733e6c7d592ed382c8a2ae5068b9dc6d4ad 47417d1eb26960bb10d1d01a7cacae3ce130fd81d1bf42957e80a2857387bcc994a12044ee2464 4e1c84dfaaa560ce7c3baeb4afacf3b3cee733602583ecd8ce1d03dc81353c1bf47b5f1e0756a7 37306e8c0ef79396bc2886b9b486fe8e626b16b8ac35b2bae743e3fd235665b986a0379afcc55a 54d175bd86eaf5faf784cfd9cc9e0b426b287d76391c5c5943a30d1e5cb42fadcb61f753fbca80 c7c0909803344944222aa69c57671a44ac429f5b0f616c4b88d3c9b8b1d4554b958fa7137fb13c bef517bcd3e151ab7b220e99edf280cba6a46946efdc24a6041f6ae2dc077adec1455addaaf84f 18bb7e5e062e6a48a784c3c2a534e7c8aa9c60abe93039b9feba89bdff3641d674a05f95393a34 37d1535493ace628c9f57dff9af726fee2b5f57c70c00e25e0bbac0b4ac80ef0dcec043c3609a5 2621e4179368b209ab695270830283fc4b5453e27ec1134dbd7907cf69128e0a19a2eb2211547d 5fda698af2947604932621f28ec4d3a526c9e4dda3687d1e7679d66552f091b7dbfd41ffcbc5e0 7a54836d55c8488967e4ff0bf8f205ccac02c1546d2a64d70120d83f33fa5fd285c91f0732f638 f9b37918c470a455d6fd5486fe1a927459234d358587553432795018acc0753df82929f8f62f7a 75debd31ceb6f9b7240ac06d78290c6c1a556c4718a5984a58de1bff6e4b52d3cd994a6073a63c 4d9822b2a215a3db91f27b8c322d6f5418c81b751352a942f4c38deedb7109f4413520538745f5 1d19500d46b5cc2626b0f8696ee49369c59f44c846a92a0c17a5bf39d6b1182e6fe6d20e709536 f78c5ef8594e93e297d6cc6a2ec42870ee1994b973ebbadfbda9a1d1a0f3d11a5d01d8c5a368a7 852cb9017a7feb4123a596969cc0f7b95fe258b52dcf9e4da6df5a6bb468e15b733bbe6b951ba0 8c1ae1c26ff891e33612abe5efc08eb4562fcfcb8e43d6ee5f1bd8ab55259fb8eed23db11b9f99 2846ed527b7e147d9dc4ce5d1db8f27e82de53249c2dba6bd1f40615cd99fe1bf847c6d29ecda7 2ca9167c2ff0a980f334b9bceadf4de80faac2ffb0f08525b17836473c7a72b800cecbdfa200c6 5829aa9c8c007e796ee95cbd6ca5546baadaaba504f5c68522463d96544e7d13f875ba80e6ca66 829ed32258111673eaf41033765e7d08c8bc196d9b99572a8271c162510fc0de4da824f467eb81 04faa0ad51148c29213f5c86779c2bb761b098efd957d388b17b9efe803b320c286ad7c36d9170 132fdd2a3ad1b71ec3fcbdc7c9f2049f98be6bb359e0c38d0437e3096f1168459be730001dc46e e2a09473b0f361080e122c1c0c5df6d09ad9f70cae402c3f09f152ae66fdfd1a4e62c65184c395 cc8b12b909eb3f5a24af4270d5f4c54f9af4d70c5b4e624bd05dd95116578e9e968e8e8e101fcf 5c0415e90e61043da57f00fa305c353d120000 simonpj@MSRC-3645512:~$ | -----Original Message----- | From: ghc-devs On Behalf Of Viktor | Dukhovni | Sent: 11 March 2021 19:05 | To: ghc-devs@haskell.org | Subject: Re: WSL2 | | On Thu, Mar 11, 2021 at 12:21:15PM +0000, 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.

Viktor Dukhovni

3:36 p.m.

New subject: WSL2

On Thu, Mar 11, 2021 at 07:53:20PM +0000, 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", ["getent", "group", "xyzzy0"], 0x7ffeb59f7a30 /* 26 vars */) = 0 brk(NULL) = 0x55cb17d10000 ... [ initialisation ] ... openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3 close(3) = 0 ... [ loading code for "files" ] ... openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 3 read(3, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 828 read(3, "", 4096) = 0 ... [ no match in "/etc/group" ] ... openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 3 ... [ loading code for "systemd" ] ... socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3 connect(3, {sa_family=AF_UNIX, sun_path=@"userdb-16b836ad920fd3bea17e1fa40e9f2f3c"}, 42) = -1 ECONNREFUSED (Connection refused) close(3) = 0 ... [ failing to connect to systemd socket ] ... openat(AT_FDCWD, "/run/systemd/userdb/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory) ... [ failing to directly access the data ] ... exit_group(2) = ? ... [ "not found" exit status ] ...

...

== Tracing getgrnam xyzzy0 (null)((nil)) No such process(3) execve("./getgrnam", ["./getgrnam", "xyzzy0"], 0x7fff81dc1c38 /* 26 vars */) = 0 ... openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3 ... openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 3 read(3, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 828 read(3, "", 4096) = 0 ... openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 3 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3 connect(3, {sa_family=AF_UNIX, sun_path=@"userdb-2cecd700b3e3705ac56ef006755c59a9"}, 42) = -1 ECONNREFUSED (Connection refused) openat(AT_FDCWD, "/run/systemd/userdb/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory) write(1, "(null)((nil)) No such process(3)"..., 33) = 33 ... [ same as getent(1), errno is from user-land, otherwise would have been ENOENT, not ESRCH ]

...

== Tracing getent group root root:x:0: execve("/usr/bin/getent", ["getent", "group", "root"], 0x7ffea01ff4f0 /* 26 vars */) = 0 ... openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3 ... openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 3 read(3, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 828 write(1, "root:x:0:\n", 10) = 10 ... [ found a match in /etc/group ] ... exit_group(0) = ? ... [ success exit ] ...

...

== Tracing getgrnam root root(0x7ffc07bd1490) Success(0) execve("./getgrnam", ["./getgrnam", "root"], 0x7ffe5f593598 /* 26 vars */) = 0 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 3 read(3, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 828 write(1, "root(0x7ffc07bd1490) Success(0)\n", 32) = 32 exit_group(0) = ? ... [ ditto ] ...

Simon Peyton Jones

3:45 p.m.

New subject: 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 +0000, 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", ["getent", "group", "xyzzy0"], | 0x7ffeb59f7a30 /* 26 vars */) = 0 | brk(NULL) = 0x55cb17d10000 | ... [ initialisation ] ... | openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", | O_RDONLY|O_CLOEXEC) = 3 | close(3) = 0 | ... [ loading code for "files" ] ... | openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 3 | read(3, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 828 | read(3, "", 4096) = 0 | ... [ no match in "/etc/group" ] ... | openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_systemd.so.2", | O_RDONLY|O_CLOEXEC) = 3 | ... [ loading code for "systemd" ] ... | socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3 | connect(3, {sa_family=AF_UNIX, sun_path=@"userdb- | 16b836ad920fd3bea17e1fa40e9f2f3c"}, 42) = -1 ECONNREFUSED (Connection | refused) | close(3) = 0 | ... [ failing to connect to systemd socket ] ... | openat(AT_FDCWD, "/run/systemd/userdb/", | O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file | or directory) | ... [ failing to directly access the data ] ... | exit_group(2) = ? | ... [ "not found" exit status ] ... | | > == Tracing getgrnam xyzzy0 | > (null)((nil)) No such process(3) | execve("./getgrnam", ["./getgrnam", "xyzzy0"], 0x7fff81dc1c38 /* | 26 vars */) = 0 | ... | openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", | O_RDONLY|O_CLOEXEC) = 3 | ... | openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 3 | read(3, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 828 | read(3, "", 4096) = 0 | ... | openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_systemd.so.2", | O_RDONLY|O_CLOEXEC) = 3 | socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3 | connect(3, {sa_family=AF_UNIX, sun_path=@"userdb- | 2cecd700b3e3705ac56ef006755c59a9"}, 42) = -1 ECONNREFUSED (Connection | refused) | openat(AT_FDCWD, "/run/systemd/userdb/", | O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file | or directory) | write(1, "(null)((nil)) No such process(3)"..., 33) = 33 | ... [ same as getent(1), errno is from user-land, | otherwise would have been ENOENT, not ESRCH ] | | > == Tracing getent group root | > root:x:0: | execve("/usr/bin/getent", ["getent", "group", "root"], | 0x7ffea01ff4f0 /* 26 vars */) = 0 | ... | openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", | O_RDONLY|O_CLOEXEC) = 3 | ... | openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 3 | read(3, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 828 | write(1, "root:x:0:\n", 10) = 10 | ... [ found a match in /etc/group ] ... | exit_group(0) = ? | ... [ success exit ] ... | | > == Tracing getgrnam root | > root(0x7ffc07bd1490) Success(0) | execve("./getgrnam", ["./getgrnam", "root"], 0x7ffe5f593598 /* 26 | vars */) = 0 | openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", | O_RDONLY|O_CLOEXEC) = 3 | openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 3 | read(3, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 828 | write(1, "root(0x7ffc07bd1490) Success(0)\n", 32) = 32 | exit_group(0) = ? | ... [ ditto ] ... | _______________________________________________ | 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- | devs&data=04%7C01%7Csimonpj%40microsoft.com%7C45a66bb32c394418ea61 | 08d8e4cd6b23%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637510918226 | 583068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ | BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hNJpeFwl8DTDXAyzfdfNFnawU | YmQ3BnNqhlYgEMRxAM%3D&reserved=0

Ben Gamari

7:25 p.m.

New subject: WSL2

Viktor Dukhovni writes:

...

On Thu, Mar 11, 2021 at 07:53:20PM +0000, 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

Simon Peyton Jones

7:22 a.m.

New subject: 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", | &g, buf, sizeof(buf), &p); | 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- | devs&data=04%7C01%7Csimonpj%40microsoft.com%7C48a10ad0766c4dd6caf4 | 08d8e4829c7d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637510597246 | 441070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ | BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nQdF9H7BpTqQL%2Bm0URWQmXh | 1KEQAV1KgfPvG75mOR%2B0%3D&reserved=0

1537

Age (days ago)

1538

Last active (days ago)

List overview

Download

11 comments

4 participants

participants (4)

Ben Gamari
Simon Peyton Jones
Tom Ellis
Viktor Dukhovni

Re: WSL2

Tom Ellis

Tom Ellis

tags

participants (4)