smtp "fatal: unknown service: smtp/tcp", probably after libc upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GLibC |
Fix Released
|
Medium
|
|||
glibc (Ubuntu) |
Fix Released
|
High
|
Balint Reczey | ||
Hirsute |
Fix Released
|
High
|
Balint Reczey | ||
postfix (Ubuntu) |
Invalid
|
High
|
Unassigned | ||
Hirsute |
Invalid
|
High
|
Unassigned |
Bug Description
On hirsute, on Jan 20, postfix stopped sending outgoing mails with the error
Feb 22 23:35:18 pccross postfix/smtp[9582]: fatal: unknown service: smtp/tcp
There were no changes in the system other than daily upgrades.
Strace shows that `smtp` process (while chrooted), after successful open of the file in the queue, tried to use NSS, ran `fstat()` against `/etc/nsswitch.
There was a big upgrade between the last successful and the first unsuccessful email delivery, and among other things libc was updated from 2.32-0ubuntu6 to 2.33-0ubuntu2. I suspect that there was some change in the NSS in libc that resulted in the failure of `getservbyname()`.
Is anybody else observing this problem?
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: postfix 3.5.6-1
ProcVersionSign
Uname: Linux 5.10.0-14-generic x86_64
ApportVersion: 2.20.11-0ubuntu59
Architecture: amd64
CasperMD5CheckR
CurrentDesktop: X-Cinnamon
Date: Tue Feb 23 00:02:13 2021
EtcMailname: pccross.average.org
Hostname: pccross
PostconfMydomain: localdomain
PostconfMyhostname: pccross.localdomain
PostconfMyorigin: /etc/mailname
ResolvConf:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search average.org
SourcePackage: postfix
UpgradeStatus: No upgrade log present (probably fresh install)
CVE References
Changed in postfix (Ubuntu): | |
status: | Incomplete → New |
tags: | added: server-next |
Changed in glibc (Ubuntu): | |
assignee: | nobody → Balint Reczey (rbalint) |
tags: | added: fr-1202 |
tags: | removed: rls-hh-incoming |
Changed in glibc: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
I have an issue that I suspect is caused by a recent glibc change, but I haven't 100% ruled out another cause, so this report might be bogus.
I use PHP-FPM [1] with chroots enabled. Since upgrading glibc, name resolving (via DNS) fails with "getaddrinfo failed: System error" in my chroot and I'm pretty sure it is caused by the recently added "Block attempts to dlopen any module we haven't already opened" [2]
What seems to happen is that the PHP-FPM master process only loads libnss_files.so.2 and libnss_systemd.so.2 because it uses that to resolve the username (it matches nsswitch which contains: "passwd: files systemd")
If any of the FPM workers then attempts to perform dns resolving, that fails because libnss_dns.so.2 has not been loaded yet (even though I made it available in the chroot), and due to the recent change, it won't be loaded either.
I have confirmed I can "fix" it by forcing the fpm master to load the dns module by modifying nsswitch.conf outside of the chroot to contains "passwd: dns files systemd", this fixes it
1. https:/ /www.php. net/manual/ en/install. fpm.php /github. com/bminor/ glibc/commit/ 429029a73ec2dba 7f808f69ec8b9e3 d84e13e804# diff-9305f19921 44bc8c923a840d4 4827642f1c3f57e 3df85a69357fff2 fe7370fb8R352
2. https:/