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.