> 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:
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.
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 ===== SOCK_CLOEXEC| SOCK_NONBLOCK, 0) = 14 "/var/run/ nscd/socket" }, 110) = -1 ENOENT (No such file or directory) SOCK_CLOEXEC| SOCK_NONBLOCK, 0) = 14 "/var/run/ nscd/socket" }, 110) = -1 ENOENT (No such file or directory) AT_FDCWD, "/etc/nsswitch. conf", {st_mode= S_IFREG| 0644, st_size=699, ...}, 0) = 0 AT_FDCWD, "/", {st_mode= S_IFDIR| 0755, st_size=4096, ...}, 0) = 0
[pid 224329] socket(AF_UNIX, SOCK_STREAM|
[pid 224329] connect(14, {sa_family=AF_UNIX, sun_path=
[pid 224329] close(14) = 0
[pid 224329] socket(AF_UNIX, SOCK_STREAM|
[pid 224329] connect(14, {sa_family=AF_UNIX, sun_path=
[pid 224329] close(14) = 0
[pid 224329] newfstatat(
[pid 224329] newfstatat(
[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 ==== SOCK_CLOEXEC| SOCK_NONBLOCK, 0) = 14 "/var/run/ nscd/socket" }, 110) = -1 ENOENT (No such file or directory) SOCK_CLOEXEC| SOCK_NONBLOCK, 0) = 14 "/var/run/ nscd/socket" }, 110) = -1 ENOENT (No such file or directory) AT_FDCWD, "/etc/nsswitch. conf", {st_mode= S_IFREG| 0644, st_size=699, ...}, 0) = 0 S_IFREG| 0644, st_size=177082, ...}, AT_EMPTY_PATH) = 0 "/etc/ld. so.nohwcap" , F_OK) = -1 ENOENT (No such file or directory) 64-linux- gnu/glibc- hwcaps/ x86-64- v2/libnss_ db.so.2" , O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) AT_FDCWD, "/lib/x86_ 64-linux- gnu/glibc- hwcaps/ x86-64- v2", 0x7ffc010b03a0, 0) = -1 ENOENT (No such file or directory) 64-linux- gnu/tls/ x86_64/ x86_64/ libnss_ db.so.2" , O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) AT_FDCWD, "/lib/x86_ 64-linux- gnu/tls/ x86_64/ x86_64" , 0x7ffc010b03a0, 0) = -1 ENOENT (No such file or directory)
[pid 224736] socket(AF_UNIX, SOCK_STREAM|
[pid 224736] connect(14, {sa_family=AF_UNIX, sun_path=
[pid 224736] close(14) = 0
[pid 224736] socket(AF_UNIX, SOCK_STREAM|
[pid 224736] connect(14, {sa_family=AF_UNIX, sun_path=
[pid 224736] close(14) = 0
[pid 224736] newfstatat(
[pid 224736] openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 14
[pid 224736] newfstatat(14, "", {st_mode=
[pid 224736] mmap(NULL, 177082, PROT_READ, MAP_PRIVATE, 14, 0) = 0x7f35ad920000
[pid 224736] close(14) = 0
[pid 224736] access(
[pid 224736] openat(AT_FDCWD, "/lib/x86_
[pid 224736] newfstatat(
[pid 224736] openat(AT_FDCWD, "/lib/x86_
[pid 224736] newfstatat(
... many more lines from internal `dlopen()` ...
[pid 224736] openat(AT_FDCWD, "/etc/services", O_RDONLY|O_CLOEXEC) = 14 S_IFREG| 0644, st_size=12966, ...}, AT_EMPTY_PATH) = 0
[pid 224736] newfstatat(14, "", {st_mode=
[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.