Message boards :
Number crunching :
How to stop getting copies of the same computer
Message board moderation
Author | Message |
---|---|
Send message Joined: 13 Jul 05 Posts: 456 Credit: 75,142 RAC: 0 |
Everybody who has this problem: please Please do do this as soon as possible - the more people who clean up this bug the better for all of us. OK, the admins will need to upgrade the server to sort out the bug, but there is a simple workaround that each of us can do to make our own boxes immune from it. This is a repeat of a post made by me about a month ago, which itself was based on original advice by Steve Cressman back in June (here). I am re-posting it (and breaking my own usual advice) as people are still asking how to do this and we need as many to know as possible. Big thanks to others who have passed the word along, especially 'Peter' who re-posted the advice over on SETI. Please do do this for each afflicted machine - my suggestion is to do one machine at a time tho 1. Stop BOINC(*). 2. Go to the website and merge all the hosts that are clones of the same machine. 3. Note the hostid of the merged machine. 4. Edit client_state.xml in the BOINC directory/folder. One way to do this is to open it with notepad. Another is to double click on it to open it in IE, then use View Source which will open it in notepad for edit. 5. Look for <hostid>nnnnn</hostid> where nnnnn is a number, under the LHC section of the file. If you are using notepad, one way to do this is to use ctrl-F for find, then enter lhcatnome in the search box and hit return; clear the search box and enter hostid and hit return. With this particular bug it has almost certainly been corrupted to <hostid>0</hostid>, but the advice applies even if the number is different. 6. If nnnnn matches your hostid from the merge, you have done, exit without saving and restart BOINC 7. Otherwise, change nnnnn to the number you noted earlier, exit with saving the changes. 8. Restart BOINC(*). (*) Exactly how you stop and start boinc varies depending on your setup. On win boxes where it is not run as a service, file -> exit within the manager usually works to stop boinc, and Start -> Programs -> Boinc -> BoincManager usually works to restart it. On win boxes where you set it up as a service, one way is to use Control Panel -> Admin tools -> Services; Right click on BOINC, stop/start Again, for win service users, you can use net stop boinc and net start boinc from the run box, or (iirr) from the control panel. River~~ ![]() |
Send message Joined: 13 Jul 05 Posts: 456 Credit: 75,142 RAC: 0 |
In a thread on the Leiden NC board, Larry1186 adds this useful diagnostic for the problem: Another way (if you use the GUI) to check if your hostid is not set: when you launch BOINC manager it should go through all the projects that host is attached to in the messages pane: Larry also found, on the Leiden project, that it was not enough to change the hostid in client_state: I looked through the BOINC folder and found the hostid tag set to zero in several places. Changing only the client_state.xml and client_state_prev.xml did not work for me. I had to go into acct_mgr_request.xml and sched_request.xml in addition to the other two files. This changed all instances of the "hostid tag = 0" for Leiden over to the proper host ID. This tag also shows up in sched_reply.xml as well but, for me, it was already set correctly. This was not my experience on either project, but I am posting it here in case anyone else finds it necessary. If so, could the first few people who find they need to edit those other files post a message here so the devs know (when we have any devs!) Perhaps it won't be needed here - the problem arises on LHC and Leiden because both are using obsolete server code, but they could be using *different* obsolete code. R~~ |
Send message Joined: 24 Nov 06 Posts: 76 Credit: 9,035,901 RAC: 83 ![]() ![]() |
Wow. Someone owes me a dinner.... I just merged several THOUSAND machines...all one click at a time. Talk about RSI! (No, I could not use the "select all" option, as the computers were all jumbled together. Ugh) On the upside, in doing so, I noticed that another project I just attached to was having the same problem. So I was able to update the xml files for both at the same time. Dublin, California Team: SETI.USA ![]() |
©2025 CERN