(difficult to confirm without coredump/backtraces).

Would a stack trace of automount or the sssd daemon be sufficient? If so, which sssd daemon should I trace: sssd_be, sssd_autofs, sssd?

Here's what I see when I do an strace of 'automount -m':

newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644, st_size=2980, ...}, 0) = 0
newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644, st_size=2980, ...}, 0) = 0
openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 7
newfstatat(7, "", {st_mode=S_IFREG|0644, st_size=653, ...}, AT_EMPTY_PATH) = 0
lseek(7, 0, SEEK_SET)                   = 0
read(7, "root:x:0:\nbin:x:1:\ndaemon:x:2:\ns"..., 4096) = 653
read(7, "", 4096)                       = 0
close(7)                                = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

Here's what I see when I attach strace to sssd_autofs:

recvfrom(18, "", 1536, 0, NULL, NULL)   = 0
write(0, "(2023-01-25 10:52:46): [autofs] "..., 85) = 85
getpid()                                = 1348
epoll_ctl(3, EPOLL_CTL_DEL, 18, 0x7fff6d209c8c) = 0
close(18)                               = 0
write(0, "(2023-01-25 10:52:46): [autofs] "..., 107) = 107
getpid()                                = 1348
epoll_wait(3, 0x7fff6d209e0c, 1, 2171)  = -1 EINTR (Interrupted system call)
--- SIGRT_2 {si_signo=SIGRT_2, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_int=1165744160, si_ptr=0x7efc457bd820} ---
rt_sigreturn({mask=[INT FPE USR1 USR2 PIPE]}) = -1 EINTR (Interrupted system call)
getpid()                                = 1348
epoll_wait(3, [], 1, 420)

and from an strace of sss_nsss:

write(0, "(2023-01-25 10:54:12): [nss] [cl"..., 83) = 83
getpid()                                = 1345
epoll_ctl(3, EPOLL_CTL_DEL, 22, 0x7ffdca2b446c) = 0
close(22)                               = 0
write(0, "(2023-01-25 10:54:12): [nss] [cl"..., 105) = 105
getpid()                                = 1345
epoll_wait(3, 0x7ffdca2b45ec, 1, 5949)  = -1 EINTR (Interrupted system call)
--- SIGRT_2 {si_signo=SIGRT_2, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_int=959572000, si_ptr=0x7fb93931e820} ---
rt_sigreturn({mask=[INT FPE USR1 USR2 PIPE]}) = -1 EINTR (Interrupted system call)
getpid()                                = 1345
epoll_wait(3, [], 1, 414)               = 0
getpid()                                = 1345
epoll_wait(3,

And from sss_be:

write(0, "(2023-01-25 11:11:23): [be[defau"..., 100) = 100
getpid()                                = 1251
epoll_wait(3, [{events=EPOLLIN, data={u32=2661562720, u64=94882784098656}}], 1, 5775) = 1
recvmsg(17, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\0\0\0\0A\0\0\0 \0\0\0\6\1s\0\v\0\0\0sssd.aut"..., iov_len=2048}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 48
recvmsg(17, {msg_namelen=0}, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
sendmsg(21, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\0\0\0\0A\0\0\0<\0\0\0\6\1s\0\v\0\0\0sssd.aut"..., iov_len=80}, {iov_base="", iov_len=0}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 80
getpid()                                = 1251
epoll_wait(3, 0x7ffd39a53ccc, 1, 5775)  = -1 EINTR (Interrupted system call)
--- SIGRT_2 {si_signo=SIGRT_2, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_int=-186955744, si_ptr=0x7fa6f4db4820} ---
rt_sigreturn({mask=[INT FPE PIPE]})     = -1 EINTR (Interrupted system call)
getpid()                                = 1251
epoll_wait(3, [], 1, 872)               = 0
getpid()                                = 1251

I tried to compile the trivial reproducer from the GitHub Issue you linked to, but I'm getting an error when I try to compile it:

# gcc sssd_tester.c -o sssd_tester -lsss_nss_idmap -lpthread -ldl
sssd_tester.c: In function ‘thread’:
sssd_tester.c:12:5: warning: implicit declaration of function ‘sss_getpwnam’; did you mean ‘getpwnam’? [-Wimplicit-function-declaration]
   12 |     sss_getpwnam("test", &res, buff, sizeof(buff), &errnop);
      |     ^~~~~~~~~~~~
      |     getpwnam

It looks like sss_getpwnam isn't defined in any of the header files in /usr/include, or I just can't find what package provides it.

Prentice
On 1/25/23 4:30 AM, Alexey Tikhonov wrote:
Hi,

might be https://github.com/SSSD/sssd/issues/6505 / https://bugzilla.redhat.com/show_bug.cgi?id=2143159
(difficult to confirm without coredump/backtraces).

Should be fixed in C9S/9.2
(https://composes.stream.centos.org/development/latest-CentOS-Stream/compose/BaseOS/x86_64/os/Packages/sssd-2.8.2-2.el9.x86_64.rpm ...)



On Tue, Jan 24, 2023 at 10:13 PM Prentice Bisbal <pbisbal@pppl.gov> wrote:
sssd-users,

I'm having an odd problem with autmount, that seems to be specific to
using sssd for autofs. The operating system is Springdale Open
Enterprise Linux 9.1, which is a rebuild of RHEL maintained by Princeton
University, so it should be 100% bug compatible with RHEL (and Rocky).

My configuration is using Kerberos for auth, and LDAP directory
services. When my nsswitch.conf entry for automount looks like this:

automount: sss files

Testing the configuration of automount/sssdwith 'automount -m' leads to
a segfault:

# automount -m

autofs dump map information
===========================

global options: none configured

Mount point: /p

source(s):
Segmentation fault (core dumped)

If I change nsswitch.conf to use files only or use ldap  like this:

automount: files

or this:

automount files ldap

Everything works as expected. LDAP searches using ldapsearch works just
fine, and using getent to get user and group information (which is
stored in LDAP) works just fine.  I've increased the debugging levels
for the relevant  SSSD daemons:

# egrep '^\[|debug_level' /etc/sssd/sssd.conf
[domain/PPPL]
debug_level = 8
[sssd]
debug_level = 8
[nss]
debug_level = 8
[pam]
[autofs]
debug_level = 8

Looking in the related log files the logs for my default domain show
that it is getting information from the LDAP directory, and then it
fails saying it can't contact the LDAP server:

(2023-01-24 16:01:31): [be[default]] [sysdb_set_entry_attr] (0x0200):
[RID#6] Entry
[name=/lldap:ou\3Dauto.local\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb]
has set [cache] attrs.
(2023-01-24 16:01:31): [be[default]] [sysdb_entry_attrs_diff] (0x0400):
[RID#6] Entry
[name=/pfsldap:ou\3Dauto.pfs\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb]
differs, reason: ts_cache doesn't trace this type of entry.
(2023-01-24 16:01:31): [be[default]] [sysdb_set_entry_attr] (0x0200):
[RID#6] Entry
[name=/pfsldap:ou\3Dauto.pfs\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb]
has set [cache] attrs.
(2023-01-24 16:01:31): [be[default]] [fo_resolve_service_send] (0x0100):
[RID#6] Trying to resolve service 'LDAP'
(2023-01-24 16:01:31): [be[default]] [get_server_status] (0x1000):
[RID#6] Status of server 'host-a.pppl.gov' is 'working'
(2023-01-24 16:01:31): [be[default]] [get_port_status] (0x1000): [RID#6]
Port status of port 389 for server 'host-a.pppl.gov' is 'not working'

Not only do the earlier log file entries show that sssd_bes actually
getting data from LDAP before it reports an error, but I can run queries
from this machine to our LDAP server with 'ldapsearch', and  all the
other computers in our environment, which are running CentOS 7 or Rocky
8 using the same configuration files.


--
Prentice
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue