If I enable boinc-client in system-config-services and then reboot, boinc_client starts up OK, but quickly starts to accumulate a lot of "cannot resolve hostname" errors. But then if I do "/sbin/service boinc-client restart", it no longer has any network problems. I notice in /etc/rc5.d/ that boinc-client is at S98 and NetworkManager is at S99, so perhaps it is a matter of the startup order? This is with boinc-client-6.2.15-1.20080818svn.fc10.x86_64 and NetworkManager-0.7.0-0.11.svn4229.fc10.x86_64 (rawhide), though I was having the same symptom in Fedora 9.
The F10 preview release notes say: "NetworkManager starts the network asynchronously. Users who have applications that require the network to be fully initialized during boot should set the NETWORKWAIT variable in /etc/sysconfig/network. Please file bugs about cases where this is necessary, so we can fix the applications in question."
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Hi and sorry for late response, this is indeed a BOINC bug because BOINC is not able to use network connections which appear after its start. In other words: network has to be up *before* BOINC is starting. This should be fixed in BOINC 6.4 AFAIK. I've already seen one report about this issue, it was simply caused by slow DHCP response (resulting into BOINC starting before network was up) and could be solved by delaying BOINC startup in the init script (sleep 15 or something like that). I'm setting this back to rawhide + adding FutureFeature as we can't expect it to be fixed before BOINC 6.4
(In reply to comment #3) > Hi and sorry for late response, > > this is indeed a BOINC bug because BOINC is not able to use network connections > which appear after its start. In other words: network has to be up *before* > BOINC is starting. This should be fixed in BOINC 6.4 AFAIK. > > I've already seen one report about this issue, it was simply caused by slow > DHCP response (resulting into BOINC starting before network was up) and could > be solved by delaying BOINC startup in the init script (sleep 15 or something > like that). > > I'm setting this back to rawhide + adding FutureFeature as we can't expect it > to be fixed before BOINC 6.4 But I set up a new Ubuntu 8.10 for testing boinc, and the version of boinc is 6.2.15 ,which is the same as in Fedora 10. My bonic is running stable, nevertheless, the boinc can not connect to the server. I can not join in SETI@Home project. Also, I find the service named of boinc-client is running. And then I try to run boinc in terminal. but the screen displays gstat error.... I do not know how to solve this program
Please could you try the RPM's located at http://mjakubicek.fedorapeople.org/boinc/ It is BOINC 6.4, I'd like to know whether it fixes your problem (i.e. checking for network availability) as I have no machine where I could reproduce it. Thanks in advance.
This is unfortunately still a problem with boinc-client-6.4.5-1.20081217svn.fc11.x86_64.
This appears to be filed upstream at: http://boinc.berkeley.edu/trac/ticket/707 But the milestone targeted for fixing it is "6.6".
This seems to be fixed as of boinc-client-6.6.37-2.r18632svn.fc11.x86_64.
Hm...I very surprised about this, so much that I can hardly believe it. However, the testing I've done so far confirms this to be fixed. My testing procedure (which hopefully generalize the on-start problem) was: 1) Make BOINC into a state when network communication is necessary (like attach new project). 2) Disconnect from network. 3) Restart BOINC 4) Wait until it finds out there is no network and waits. 5) Reconnect to network, wait until BOINC retries communication. I've done a lot of communication with upstream when I revealed this bug, but I got no news on this (nor the ticket linked above) for months. That's why I'm so curious...I have made a comment in the upstream ticket, will wait on response. It would be of course great if this would finally go away, this was the most annoying bug from a user perspective in my point of view as it affects pretty hard all the laptops that still change the networks and only suspend to RAM (i.e. boinc restarts only rarely).
According to users' response, this is indeed fixed now and I'm glad to close this.