From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040301 Description of problem: On an up to date installation of RHEL AS3 on a Proliant server with an Intel(R) Pentium(R) III CPU - S 1400MHz CPU, the command ypserv -p 834 crashes with a segmentation fault. The alternative syntax ypserv --port 834 works fine. According to the ypserv man page, both should work, although the "-p" version that causes the segfault is given more prominence. If the "-p" syntax is no longer supported, it should produce an error message, not a segfault, and the man page should be updated. Version-Release number of selected component (if applicable): ypserv-2.8-6 How reproducible: Always Steps to Reproduce: 1. Stop all NIS services 2. Run the command "ypserv -p 834" 3. Actual Results: The YP server failed to start, producing a "segmentation fault" error message. Expected Results: The YP server should have started. Additional info: Although "ypserv -p 834" fails, "ypserv --port 834" works OK. An alternative way to cause the problem is to add the line YPSERV_ARGS="-p 834" to /etc/sysconfig/network and run "service ypserv start".
I can confirm this on my system as well. Not good.
I can confirm this on my system too. --port worked fine but -p results in a segfault. ltrace shows a NULL pointer finding it's way into __strtol_internal() [root@sql1 root]# ltrace ypserv -p 740 __libc_start_main(...) openlog("ypserv", 1, 24) getopt_long(...) __strtol_internal(NULL, NULL, 10 <unfinished ...> --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ [root@sql1 root]# ltrace ypserv --port 740 __libc_start_main(...) openlog("ypserv", 1, 24) getopt_long(...) __strtol_internal("740", NULL, 10) getopt_long(...) fork() exit(...) +++ exited (status 0) +++
I can confirm this behavior too. Thanks for the '--port' workaround.
*** Bug 128695 has been marked as a duplicate of this bug. ***
I appreciate the --port workaround. I've noted this in both RHEL 3 and FC 2.
This looks like bug #137660 -- update to ypserv-2.8-11... -charles.
Yes, looks as if Ion Badulescu encountered the same bug about six months after me and was clever enough to find a fix. Thanks Ion. I am glad that the problem has been fixed, but disappointed that such a serious bug (which, if it had not been for the far from obvious --port workaround, would have broken all attempts to firewall NIS) received no response from Red Hat.