After updating my system, I am unable to start ypbind, and receive only the following output: root # /etc/init.d/ypbind start * ERROR: Problem starting needed services. * "ypbind" was not started. It turns out that this is related to domainname service, which in itself prints absolutely nothing: root # /etc/init.d/domainname start root # In fact, the eerror lines which do provide the necessary information to fix the problem, by adding an /etc/nisdomainname, are commented out for some reason. By breaking, and producing absolutely no error output, this update of yp-tools has proved especially annoying. To save others such hassle, can we please have the domainname script print errors when it can do nothing else. Additionally, can ypbind indicate which dependencies failed? Lastly, what is the motivation for the new configuration method and could the respective configuration files simply be created from a quick read of the old yp config files? -Jacob Reproducible: Always Steps to Reproduce:
run `emerge baselayout ypbind --noconfmem`, then `etc-update` see if your system is still broken after that
I have the same problem (baselayout-1.9.4-r6, ypbind-1.17.2-r1). Remerging them as SpanKY suggested did not fix it. ypbind only starts if a domainname is set in /etc/dnsdomainname. I'd say this is a pretty serious bug (there is no way to know from ypbind's failure message what one is supposed to do).
Indeed, SpanKY's suggestion did not work for me. Aside from the lack of error output, which absolutely needs correction, I consider the requirement for a /etc/dnsdomainname to be a significant bug in itself. It necessitates more maintenance of NIS machines and is in no way a dependency of ypbind. -Jacob
are you both running baselayout-1.9.x ?
As stated in my previous comment, I'm using baselayout-1.9.4-r6 (lastest stable x86).
so the only issue here is that ypbind isnt helpful
No, the major issue is that the ypbind initscript depends on domainname to be started. The second issue is that domainname fails silently if either the NIS domainname or the DNS domainname can't be set. Proposed solution for the first problem: It should not be necessary to set the DNS domainname for ypbind to work. Proposed solution for the second problem: The domainname script should print error messages when the checks for setting NIS and DNS domainnames fail. (There are already error messages, but they are commented out.)
> No, the major issue is that the ypbind initscript depends on domainname to be > started. How is that an issue. ypbind needs the nis domainname set. > The second issue is that domainname fails silently if either the NIS > domainname or the DNS domainname can't be set. Ok, that is a problem that should be fixed then. > Proposed solution for the first problem: It should not be necessary to set > the DNS domainname for ypbind to work. /etc/init.d/domainname sets the nis domainname as well. THAT is the required functionality.
>> No, the major issue is that the ypbind initscript depends on domainname to be >> started. >How is that an issue. ypbind needs the nis domainname set. ypbind needs the NIS domain name set, *not* the DNS domain name. Having both as a dependency unnecessarily complicates NIS setup. -Jacob
Jacob: I think you don't understand how the init scripts work. It's just saying that domainname needs to be run first... this is because it needs the nisdomain set. domainname ALSO sets the dns domainname if you want it to. This has NO consequences for NIS. Hell, if you don't want it to set the DNS domainname, then just don't have it set the DNS domainname by editing /etc/conf.d/domainname.
I think the main culprit in this problem is line 33 in /etc/init.d/domainname: local retval2=2 retval2 is used for the status of the DNS domainname check. With its default value being 2 (unlike 0 like for retval), it causes the script to always fail if no DNS domainname is set because the return statement looks like this (line 63): retval=$((retval + retval2)) This is in the latest stable baselayout (baselayout-1.9.4-r6). In the unstable baselayout (1.11.8) the retval2 line is correct (default value is 0). Funny, this is another example where I've generally had less issues with ~x86 than x86 :-P
Alright. I'm going to mark this fixed then as the issue is resolved in ~x86
Sorry to keep hammering at this, but if the issue is still present in x86, how can this bug be closed? Or is the intention to bump baselayout-1.11.8 to stable soon?
