Date: Fri, 23 Aug 2024 17:21:13 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 281012] ypldap works when invoked with -dv, but not when invoked normally (daemonised) Message-ID: <bug-281012-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281012 Bug ID: 281012 Summary: ypldap works when invoked with -dv, but not when invoked normally (daemonised) Product: Base System Version: 14.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: gray@nxg.name I can configure ypldap.conf in the fairly obvious way, so that ypldap -dv works, in the sense that I can do expected NIS lookups against it, manifest= ly getting data from my LDAP server, and I see all sorts of reassuring chatter= as it does its work. But when I relaunch the server the normal way, so that it daemonises, the same NIS lookups fail, timing out. ypldap doesn't seem to have extensive debug logs, and the process doesn't c= rash in an easily debuggable way, so I can't give much extra information. I'm afraid I'm not able to dig into this very deeply. I built a version of= the program including got-here debugging, and that seemed to get itself into a = loop with yp_fd_event being called repeatedly. But I've no experience with the event library here (and this is not the time for me to take on new projects= !), so I lack capacity to make much sense of what I'm seeing. Nothing, at any rate, jumps out when I do this. A separate odd thing, which I mention because it may or may not be related,= is that the /etc/rc.d/ypldap script includes ypldap_precmd() { force_depend ypserv nis_server || return 1 } That _seems_ to include a dependency on ypserv, but as the ypldap(8) manpage very intelligibly notes, 'ypldap has the same role as ypserv(8) and the two daemons are exclusive.' So I wonder if there's something else funny going on here. I note that ypldap has (unsurprisingly) seen very little real development w= ork in the last few years, and probably also rather little actual use, so I'm guessing a change in one or other base version has broken something here. = But that might have been a while ago, since the only online commentary I can fi= nd is at [1], from 2016, which seems to be reporting similar behaviour. [1] https://groups.google.com/g/muc.lists.freebsd.stable/c/nO0NMaSbD7o --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-281012-227>