Re: CVS hanging
I am running CVS 1.11.1 pserver. Both client and server are Sparc Solaris 7. One of my developers can't use CVS. Every request hangs. I got him to re-login but it didn't seem to make a difference. I, personally, can access CVS with no problems. We just moved some of our directories (including the CVS executables) onto another (NFS-mounted) drive. A truss of the server gives: door_call(3, 0xFFBEF678)(sleeping...) Offhand the only things that I can think of that use Doors are name-service lookup functions, e.g. getpwnam(), getpwuid(), getspnam(), getgrnam(), getgrgid(), gethostbyname(), gethostbyaddr(). The Door call means that the name-service lookup function is delegating the lookup to 'nscd', the name-service cache daemon. This is a mixed blessing; it works pretty well for files (/etc/passwd et al), NIS and NIS+, but in older Solaris releases it doesn't work so well for DNS, because the libresolv code was the horrible old Berkeleyoid BIND code that was pretty unfriendly to multithreading. This was fixed in Solaris 8 (i.e. libresolv not handles multithreading intelligently), and the fix was ported back to some of the later releases of Solaris 7. Alternatively, you can disable the nscd, either completely or per class of information (e.g. use it for passwd and group but disable it for hosts). See the man page for nscd. Be warned that there are some interesting consequences to disabling it for hosts, e.g. if you run Netscape on that box (the server) it may act up (not that Netscape doesn't act up anyway). It would be good if you could figure out whether the offending lookup was for passwd, group or hosts. See below. Not too useful, I know. Unfortunately, I can't attach to the server until after the problem occurs. You might also try /usr/proc/bin/pstack process id Thomas Maslen [EMAIL PROTECTED] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs hanging on plan 9 at end of protocol
Russ Cox [EMAIL PROTECTED] writes: Specifically, the CVS client never hangs up. The problem is in the client, since I'm using well known servers like :pserver:[EMAIL PROTECTED]:/vger, a repository for the Linux kernel source. I believe the problem is in get_responses_and_close, specifically this: if (! buf_empty_p (from_server) || getc (from_server_fp) != EOF) error (0, 0, dying gasps from %s unexpected, current_parsed_root-hostname); else if (ferror (from_server_fp)) error (0, errno, reading from %s, current_parsed_root-hostname); fclose (from_server_fp); The client hangs in the getc() there, waiting for more network data. Of course there isn't any, since the server thinks we're done. So getc() blocks waiting for network data. I confirmed that the CVS code does not try to set O_NONBLOCK on the file descriptor and that the server does not close the connection on its end (checked with tcpdump), so it seems perfectly reasonable to me that getc() blocks. Unfortunately, this means we never finish, until eventually the server times out and closes its connection. The connection closes gracefully sometimes when I'm compressing, but sometimes it doesn't. I thought maybe the server output buffer wasn't being flushed before get_responses_and_close, but I flushed it (with buf_send_output(to_server) right before buf_shutdown(to_server)) and nothing changed. Could someone more familiar with what's going on here explain to me what should be happening? Is my getc implementation broken (entirely likely)? Should the connection be opened O_NONBLOCK? Something else entirely? The client calls shutdown on the sockets which are connected to the server. This is shortly before the dying gasps code. The server should see this as EOF, and exit, closing the socket on its side. The client should see the closed socket, and getc() should return EOF. I don't know why it is not working for you, but that is how it is supposed to work. Ian ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
cvs hanging on plan 9 at end of protocol
I've compiled the CVS 1.11.1p1 sources on Plan 9 and am trying to debug some odd behavior when connecting to network CVS servers. Specifically, the CVS client never hangs up. The problem is in the client, since I'm using well known servers like :pserver:[EMAIL PROTECTED]:/vger, a repository for the Linux kernel source. I believe the problem is in get_responses_and_close, specifically this: if (! buf_empty_p (from_server) || getc (from_server_fp) != EOF) error (0, 0, dying gasps from %s unexpected, current_parsed_root-hostname); else if (ferror (from_server_fp)) error (0, errno, reading from %s, current_parsed_root-hostname); fclose (from_server_fp); The client hangs in the getc() there, waiting for more network data. Of course there isn't any, since the server thinks we're done. So getc() blocks waiting for network data. I confirmed that the CVS code does not try to set O_NONBLOCK on the file descriptor and that the server does not close the connection on its end (checked with tcpdump), so it seems perfectly reasonable to me that getc() blocks. Unfortunately, this means we never finish, until eventually the server times out and closes its connection. The connection closes gracefully sometimes when I'm compressing, but sometimes it doesn't. I thought maybe the server output buffer wasn't being flushed before get_responses_and_close, but I flushed it (with buf_send_output(to_server) right before buf_shutdown(to_server)) and nothing changed. Could someone more familiar with what's going on here explain to me what should be happening? Is my getc implementation broken (entirely likely)? Should the connection be opened O_NONBLOCK? Something else entirely? Thanks much. Russ Cox [EMAIL PROTECTED] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
