Hello @sergiodj,
> Could you perhaps provide the configuration files you used to do that?
My complete configuration is included in the tar attached to this
ticket.
> please make sure that your Hirsute system is up-to-date
Yes, updated daily, _plus_ by hand right before the investigation.
Note the that problem (quite certainly) _was triggered by an update_ of the
libc package.
Perhaps worth to mention, my systems are being upgraded between distro
versions, not fresh-installed.
In the meanwhile, I did more investigation. First, I checked that the
problem is, as I suspected, connected to running `getservbyname()` under
chroot. When I change smtp line in `master.cf` to not run under chroot,
i.e.
smtp unix - - y - - smtp
is changed to
smtp unix - - n - - smtp
MAIL DELIVERY STARTS TO WORK!
So at least I have a workaround now. But the problem still stands.
Now here is something interesting: strace of the `smtp` process when it
is run under chroot and without chroot:
===== under chroot =====
[pid 224329] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 14
[pid 224329] connect(14, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
110) = -1 ENOENT (No such file or directory)
[pid 224329] close(14) = 0
[pid 224329] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 14
[pid 224329] connect(14, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
110) = -1 ENOENT (No such file or directory)
[pid 224329] close(14) = 0
[pid 224329] newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644,
st_size=699, ...}, 0) = 0
[pid 224329] newfstatat(AT_FDCWD, "/", {st_mode=S_IFDIR|0755, st_size=4096,
...}, 0) = 0
[pid 224329] getpid() = 224329
[pid 224329] sendto(7, "<18>Feb 24 20:48:11 postfix/smtp"..., 92, MSG_NOSIGNAL,
NULL, 0) = 92
========
(the last line is the error message about "smtp"/"tcp" service. No
attempt to load any nsswitch modules!)
==== no chroot ====
[pid 224736] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 14
[pid 224736] connect(14, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
110) = -1 ENOENT (No such file or directory)
[pid 224736] close(14) = 0
[pid 224736] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 14
[pid 224736] connect(14, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
110) = -1 ENOENT (No such file or directory)
[pid 224736] close(14) = 0
[pid 224736] newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644,
st_size=699, ...}, 0) = 0
[pid 224736] openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 14
[pid 224736] newfstatat(14, "", {st_mode=S_IFREG|0644, st_size=177082, ...},
AT_EMPTY_PATH) = 0
[pid 224736] mmap(NULL, 177082, PROT_READ, MAP_PRIVATE, 14, 0) = 0x7f35ad920000
[pid 224736] close(14) = 0
[pid 224736] access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
[pid 224736] openat(AT_FDCWD,
"/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2/libnss_db.so.2",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 224736] newfstatat(AT_FDCWD,
"/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2", 0x7ffc010b03a0, 0) = -1 ENOENT
(No such file or directory)
[pid 224736] openat(AT_FDCWD,
"/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libnss_db.so.2", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
[pid 224736] newfstatat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/x86_64",
0x7ffc010b03a0, 0) = -1 ENOENT (No such file or directory)
... many more lines from internal `dlopen()` ...
[pid 224736] openat(AT_FDCWD, "/etc/services", O_RDONLY|O_CLOEXEC) = 14
[pid 224736] newfstatat(14, "", {st_mode=S_IFREG|0644, st_size=12966, ...},
AT_EMPTY_PATH) = 0
[pid 224736] lseek(14, 0, SEEK_SET) = 0
[pid 224736] read(14, "# Network services, Internet sty"..., 4096) = 4096
[pid 224736] close(14)
========
So it looks like for some reason, dlopen() decided that it cannot /
should not try to load shared libraries, thus preventing nsswitch
operation. Perhaps `ldopen()` the new version of libc is more sensitive
to some file permissions, or absence of some files in the "fake root"
than the previous?
In any case, the problem is very likely in some peculiarity of dlopen in
the new libc.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1916541
Title:
smtp "fatal: unknown service: smtp/tcp", probably after libc upgrade
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1916541/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
