Version: (using KDE KDE 3.0.99) Installed from: Compiled From Sources Compiler: gcc 2.95.3 OS: Solaris During startup, KDE hangs (ksplash showing "Initializing peripherals") as I already mentioned (the third issue) on kde-solaris (see http://lists.kde.org/?l=kde-solaris&m=103717896719055&w=2). I managed to track this down a little bit: We're using NIS as a system for passwd/group/netgroup information and DNS for hostname resolution (config running perfectly for _years_ and working flawlessly with 3.1beta1). The DNS domainname is different from the NIS domainname (the latter being the lowercase form of the first which is mixed-case). Somehow something inside KDE (not sure right now where to look) tries to use the DNS domainname as the NIS domain, trussing ypbind shows it's trying to open /var/yp/binding/<DNSdomain>/ypservers. For testing purposes I created a symlink pointing to the correct place which would allow me to log in finally, but kcheckpass still wouldn't unlock the screen. If called manually it just hangs (trying to communicate with ypbind I assume). trussing 3.1beta1's kcheckpass shows that it's using sysinfo(SI_SRPC_DOMAIN) which obvoiusly succesds, whereas 3.1RC3's does something else. I already browsed through the CVS logs but could not find any changes that might be related to this problem :-(
FWIW: for testing purposes I replaced getdomainname() in kdelibs/kdecore/fakes.c with a call to sysinfo(SI_SRPC_DOMAIN) and this seems to solve my problem (I can log in now and unlocking the screensaver works as well). But I'm almost sure that this is NOT the correct way to fix the problem, since this obviously doesn't cover the generic case NIS-DomainName != DNS-DomainName. OTOH I'm not sure if choosing different domain names in these naming systems is a feasable setup in the first place...
Just wanted to note that we have the same problem here with a very similar setup. Our NIS domain name is kogs.informatik... but our DNS domain name is only informatik... While our sysadmin says that one might prefer them to be identical, the don't have to be and that won't be changed here. So, for now I have to live without KDE3.1 until someone (or I) finds out where the DNS domain name is improperly used to query the NIS server, probably for simple stuff like use name/home dir since it happens already on startup (in "LD_BIND_NOW=true kdeinit +kcminit +knotify"). Remember: As Torsten stated - I can't verify that right now - 3.1beta1 still worked, so something must have changed since then.
a Linux NIS hinted me that this might really related to the getdomainname function indeed. Does your KDE compile without the getdomainname function in kdefakes at all (perhaps it's defined in libnsl or libsocket instead). The theory is that Solaris has a getdomainname for NIS function that KDE overrides with it's getdomainname function for DNS. This may explain the results you're getting. But what it doesn't explain is, why it worked with KDE 3.0 as the getdomainname is for longer in there. I would perhaps start kdeinit in a debugger, set a breakpoint in getdomainname (after having hit the break point in main) and then check from where it reaches this break point.
Obviuosly, there is a getdomainname() function in libnsl, but this interface doesn't seem to be documented (Solaris 8): I couldn't find neither a manpage nor a protoype in the header files... What _is_ documented is yp_get_default_domain() which, according to the manpage, is equivalent to using the SI_SRPC_DOMAIN command for sysinfo(2). Anyway, I'm currently compiling from a clean cvs source tree in order to try to debug where the getdomainname() call is coming from. But I'd almost vote for replacing the getdomainname() in kdefakes with the system's implementation (where available). I'll provide a patch if Stephan considers this is appropriate.
Subject: Re: KDE startup hangs due to invalid NIS(YP) domainname On Dienstag, 17. Dezember 2002 17:06, you wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=50754 > > > > > ------- Additional Comments From tk@Genetik.Uni-Bielefeld.DE 2002-12-17 > 17:06 ------- Obviuosly, there is a getdomainname() function in libnsl, but > this interface doesn't seem to be documented (Solaris 8): I couldn't find > neither a manpage nor a protoype in the header files... Then the one in kdefakes shouldn't even be used. Greetings, Stephan > > What _is_ documented is yp_get_default_domain() which, according to the > manpage, is equivalent to using the SI_SRPC_DOMAIN command for sysinfo(2). > > Anyway, I'm currently compiling from a clean cvs source tree in order to > try to debug where the getdomainname() call is coming from. But I'd almost > vote for replacing the getdomainname() in kdefakes with the system's > implementation (where available). I'll provide a patch if Stephan considers > this is appropriate.
Yes, but configure currently doesn't check for this function in libnsl, so it doesn't detect its presence: --- snip --- configure:30468: checking for getdomainname configure:30514: g++ -c -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -pedanti c -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -fno-builtin -g -O2 -f no-exceptions -fno-check-new -pedantic-errors -DQT_THREAD_SUPPORT -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_SOLARIS -DSVR4 conftest.cc >&5 configure: In function `int main()': configure:30504: `getdomainname' undeclared (first use this function) configure:30504: (Each undeclared identifier is reported only once configure:30504: for each function it appears in.) configure:30517: $? = 1 configure: failed program was: #line 30491 "configure" #include "confdefs.h" #include <stdlib.h> #include <unistd.h> int main () { char buffer[200]; getdomainname(buffer, 200); ; return 0; } configure:30544: result: no configure:30547: checking if getdomainname needs custom prototype configure:30637: result: yes - in libkdefakes --- snip --- Anyway, I don't think it's a good idea to rely on an undocumented interface, and since sysinfo(2) is documented, this is perhaps the way to go?
Subject: Re: KDE startup hangs due to invalid NIS(YP) domainname Am Dienstag, 17. Dezember 2002 18:25 schrieben Sie: > Anyway, I don't think it's a good idea to rely on an undocumented > interface, and since sysinfo(2) is documented, this is perhaps the way to > go? This would be highly solaris dependent afaik. at least on linux sysinfo is defined as this: int sysinfo(struct sysinfo *info); No, the configure check has to be fixed to take libnsl into account. Greetings, Stephan
I (suffering the same bug) made the following observation. One difference between kde3.1-rc? (where this bug occurs) and kde3.04 (where everything ran without any probs) is in config.h. With kde3.04 I had #define HAVE_GETDOMAINNAME 1 whereas in kde3.1-rc? there is /*#undef HAVE_GETDOMAINNAME */ Interestingly, if I manually change my config.h (after running configure) to contain #define HAVE_GETDOMAINNAME 1, the bug disappears. I must admit, that I do not understand at all, why this is the case. BTW, in kdecore/fakes.c the procedure getdomainname is not compiled in either of the above cases, since it is masked by #if !defined(HAVE_GETDOMAINNAME) Greetings, oliver
I removed getdomainname now from kdelibs. Please one of you: try to compile KDE CVS HEAD, if it works out I'll backport my changes to 3.1
Ok, I'm currently compiling -- a little bit OT: configure seems to lack a test for <sys/stropts.h> and thus does not define HAVE_SYS_STROPTS_H which currently breaks the compilation for kdelibs/kdecore/kprocess.cpp. I fixed this by manually editing config.h cheers, Torsten
Hi Stephan, I finished installing kdelibs & kdebase and it seems to work ok so far... cheers, Torsten
Using the 3_1_BRANCH, I had success #defining HAVE_GETDOMAINNAME in config.h which - as coolo noted - only has impact on fakes.c. That means: Yes, removing getdomainname there was the right bug fix and should be backported.
Subject: KDE_3_1_BRANCH: / CVS commit by mueller: backport getdomainname removal from HEAD. CCMAIL: 50754@bugs.kde.org M +1 -1 kde-common/admin/acinclude.m4.in 2.302.2.20 M +2 -2 kdebase/kdm/backend/client.c 2.25.2.1 M +0 -1 kdelibs/configure.in.in 1.92.2.5 M +0 -44 kdelibs/kdecore/fakes.c 1.9.2.4 --- kdebase/kdm/backend/client.c #2.25:2.25.2.1 @@ -931,5 +931,5 @@ StartClient (struct display *d, for (i = 0; i < d->authNum; i++) { -#ifdef SECURE_RPC +#if defined(SECURE_RPC) && defined(HAVE_GETDOMAINNAME) if (d->authorizations[i]->name_length == 9 && memcmp(d->authorizations[i]->name, "SUN-DES-1", 9) == 0) --- kdelibs/configure.in.in #1.92.2.4:1.92.2.5 @@ -145,5 +145,4 @@ AC_CHECK_INITGROUPS AC_CHECK_USLEEP -AC_CHECK_GETDOMAINNAME AC_CHECK_GETHOSTNAME AC_CHECK_RANDOM --- kde-common/admin/acinclude.m4.in #2.302.2.19:2.302.2.20 @@ -2050,5 +2050,5 @@ else case "$1" in - setenv|unsetenv|usleep|getdomainname|random|srandom|seteuid|mkstemps|mkstemp|revoke|vsnprintf|strlcpy|strlcat) + setenv|unsetenv|usleep|random|srandom|seteuid|mkstemps|mkstemp|revoke|vsnprintf|strlcpy|strlcat) kde_cv_proto_$1="yes - in libkdefakes" ;; --- kdelibs/kdecore/fakes.c #1.9.2.3:1.9.2.4 @@ -130,48 +130,4 @@ void usleep(unsigned int usec) { #endif -#if !defined(HAVE_GETDOMAINNAME) - -#include <sys/utsname.h> -#include <netdb.h> -#include <strings.h> -#include <errno.h> -#include <stdio.h> - -int getdomainname(char *name, size_t len) -{ - struct utsname uts; - struct hostent *hent; - int rv = -1; - - if (name == 0L) - errno = EINVAL; - else - { - name[0] = '\0'; - if (uname(&uts) >= 0) - { - if ((hent = gethostbyname(uts.nodename)) != 0L) - { - char *p = strchr(hent->h_name, '.'); - if (p != 0L) - { - ++p; - if (strlen(p) > len-1) - errno = EINVAL; - else - { - strcpy(name, p); - rv = 0; - } - } - } - } - } - return rv; -} - - -#endif - #ifndef HAVE_RANDOM long int random()
FYI, for documentation, I too had a hang on KDE startup (Solaris 8) and checking out KDE_3_1_BRANCH with Dirk's patch fixed it. At least one other person on kde-solaris probably has the same problem. This may be something for the FAQ, at least until 3.1.1.
Fixed in KDE 3.1.1