GNOME Bugzilla – Bug 347632
down news server locks up pan
Last modified: 2006-09-06 19:19:42 UTC
I normally read all my news from a text-only feed using the free news.readfreenews.net service as primary. I occasionally need to pick up a binary, and then use the biggulp.readfreenews.net feed as my also-free secondary. As per the announcement at http://www.readfreenews.net/ biggulp is down until the end of July. This secondary-site-down scenario causes pan to simply hang forever. It is completely unuseable, and locks up even when attempting to remove the down newsfeed site from the config. The only recovery that I've found is to delete the .pan2 directory and lose all subscriptions, history, etc. I'm running the rpm-packaged pan version 0.102-1 on almost-stock Fedora Core 5 on AMD Thunderbird (IA32) hardware.
I tried to duplicate this setup with news.readfreenews.net as a primary and biggulp as the secondary. text articles are fetched successfully from news.readfreenews.net, but binaries fail there, so Pan tries to connect to biggulp and gets a connection refused. Pan doesn't seem to lock up as you describe. The tasks do sit frozen, as there's nothing that can complete them. But it doesn't lock up. What am I doing wrong? (Side note: "delete server" doesn't work. This is a separate issue, #337319)
What would happen if the newsserver system is totally down ? Is Pan doing asynchronous connects? If not, the connect call will block (and therefore hang Pan) until TCP timeout occurs.
No, the connection attempts are synchronous. I'd welcome a patch that would change this -- it would be easy enough to wire the new code back into the Task/Queue/Pool hierarchy because the Pool, which creates the socket, doesn't need it to be synchronous. Even a patch that reintroduced threads would be welcomed so long as they're only used for this one single purpose only. :)
Changed from blocker to major. This is only a problem with down news servers that don't even refuse connection; rather, they just totally block completely. This isn't a common problem. However it is a very serious problem for people who it it, at least until the "disable news server" toggle discussed in pan-users is implemented.
*** Bug 348731 has been marked as a duplicate of this bug. ***
*** Bug 348741 has been marked as a duplicate of this bug. ***
*** Bug 337560 has been marked as a duplicate of this bug. ***
*** Bug 350540 has been marked as a duplicate of this bug. ***
Hi Charles, I have not been studying the source so I don't now if this is already implemented. It could be an idea to wrappe all sockets inside a select Something like: /* Every socket in fds[max_sockets] needs to be non-blocking */ void handle_connections(int fds[max_sockets]) { fd_set watch; fd_set ready; int i, read_bytes, maxfd; struct timeval timeout; timeout.tv_sec = 20; timeout.tv_usec = 0; FD_ZERO(&watch); for (i = 0; i < max_sockets; ++i) FD_SET(fds[i], &watch); maxfd = get_maxfd(fds); select(maxfd + 1, &ready, NULL, NULL, &timeout); for (i = 0; i < max_sockets, ++i) { if (FD_ISSET(fds[i], &ready)) { read_bytes = read_from_socket(); if (read_bytes < 0) error(); else if (!read_bytes) { close_socket(fds[i]); FD_CLR(fds[i], &watch); } else handle_response(fds[i]); } } }
Glib already does this. GIOChannel sets the sockets to non-blocking and the main-loop uses select. This may be the same bug I just found when using biggulp. While getting overviews the connection was dropped. Pan reported -1 idle connections & 1 active connection. I have biggulp set to use only 1 connection. This causes pan to never reconnect to the server.
bug 354405 should fix this right?
Yep.