Bug 1216141

Summary: "Servname not supported for ai_socktype" after /etc/services moved to /usr/etc/
Product: [openSUSE] openSUSE Tumbleweed Reporter: Georg Pfuetzenreuter <georg.pfuetzenreuter>
Component: NetworkAssignee: E-mail List <screening-team-bugs>
Status: RESOLVED INVALID QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: kukuk
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: openSUSE Tumbleweed   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: strace

Description Georg Pfuetzenreuter 2023-10-11 13:47:28 UTC 
Created attachment 870096 [details]
strace

Hi,

trying to run `whois` on a recent Tumbleweed snapshot fails:

```
$ whois 88.208.74.89
getaddrinfo(whois.ripe.net): Servname not supported for ai_socktype
```

This seems to be a regression from /etc/services moving to /usr/etc, since 

```
# cp /usr/etc/services /etc/
```

mitigates the issue.

Note that I did not have any other file in /etc/services before the `cp` call.

It seems `nscd` is involved as well, since `whois` continues to work after removing `/etc/services` again for as long as I keep `nscd` running.

I will attach strace output of a failing `whois` operation in case it's useful.

Best,
Georg
Comment 1 Thorsten Kukuk 2023-10-12 09:59:29 UTC 
whois works fine on my system.

Since you have an own copy of /etc/nsswitch.conf, I bet you have that misconfigured and /usr/etc lookup is disabled. Please enable that again, else it will of course not work.
Comment 2 Georg Pfuetzenreuter 2023-10-12 10:06:42 UTC 
Hi,

I didn't recall modifying nsswitch, but upon opening it:

```
$ more /etc/nsswitch.conf
# bla bla bla
```

I suppose I created this at some point to suppress the enormous amount of "No such file or directory" log messages nscd is printing to the journal about the file not being found.

I now deleted the bogus `/etc/nsswitch.conf` and `whois` seems to operate even after `nscd` restarts.

Thank you for the hint!

I recall some other bug about the bogus log messages but cannot find it for reference.