I Installed Boinc on a CLI only debian system following this instruction:

http://boinc.berkeley.edu/wiki/Installing_BOINC_on_Debian

but when I try to run boinccmd I will get a Error -102: read() failed
and when I try to run boinc I will get gstate.init() failed Error Code: -180

Any idea to fix this? Thanks.

BOINC error code -102 means that you don't seem to have permission to read from or write to the BOINC data directory. Check permissions.
BOINC error code -180 means that the GUI RPC bind failed. Can also have to do with lack of permissions.

---

Thanks, I changed permission of all files in /var/lib/boinc-client/ to 777 but still no luck :(

What's in gui_rpc_auth.cfg? There's been reports on other distros that this file is non-existent or when it exists that it's empty.

What happens when you start boinc-client --no_gui_rpc (or boinc --no_gui_rpc) and then do boinccmd?

Is anything else using port 31416?
See what the outcome is of:

lsof -i:31416

---

The "gui_rpc_auth.cfg" is empty, it seems this file should contains password? I put a string in it and run "boinccmd --host localhost --passwd <string I put in> --get_state" this time I get "Authorization failure: -102"

Also I can use "boinc --no_gui_rpc" to start boinc.

Port 31416 is not in use, "lsof -i:31416" returns empty.

Hope these things can help.

The "gui_rpc_auth.cfg" is empty, it seems this file should contains password? I put a string in it and run "boinccmd --host localhost --passwd <string I put in> --get_state" this time I get "Authorization failure: -102"

I'm not too sure anymore if there needs to be something in the gui_rpc_auth.cfg file for Linux. Will have to ask the developers about that, but I also need to stress that this is done by the package maintainers. You're not running Berkeley BOINC, but a BOINC compiled by the package maintainer of Debian.

I don't say I don't want to help you, or can't help you (even though my knowledge of Linux is limited, I must admit), but you best ask the Debian package maintainers as well. If you can, of course.

Also I can use "boinc --no_gui_rpc" to start boinc.

Port 31416 is not in use, "lsof -i:31416" returns empty.

Hold on, did you do the lsof command after running boinc --no_gui_rpc? As then it's normal that port 31416 isn't used. You just told BOINC to not use the GUI RPC port.

This GUI RPC port is used by BOINC to communicate between its parts. Not just between boinc and boincmgr, but also between boinc and boinccmd. So, can you run boinccmd after you did boinc --no_gui_rpc?

---

Thanks for your help, I've tried every combination but unfortunately no help. I will try to compile a Berkeley boinc from source code to see if it can help.

OK, when you do, make sure to compile the client_release/7/7.0b branch, not Master.

http://boinc.berkeley.edu/trac/wiki/SourceCodeGit and http://boinc.berkeley.edu/trac/wiki/CompileClient should be of help.

---

The "gui_rpc_auth.cfg" is empty, it seems this file should contains password? I put a string in it and run "boinccmd --host localhost --passwd <string I put in> --get_state" this time I get "Authorization failure: -102"

I'm not too sure anymore if there needs to be something in the gui_rpc_auth.cfg file for Linux. Will have to ask the developers about that, but I also need to stress that this is done by the package maintainers. You're not running Berkeley BOINC, but a BOINC compiled by the package maintainer of Debian.

I don't say I don't want to help you, or can't help you (even though my knowledge of Linux is limited, I must admit), but you best ask the Debian package maintainers as well. If you can, of course.

Also I can use "boinc --no_gui_rpc" to start boinc.

Port 31416 is not in use, "lsof -i:31416" returns empty.

Hold on, did you do the lsof command after running boinc --no_gui_rpc? As then it's normal that port 31416 isn't used. You just told BOINC to not use the GUI RPC port.

This GUI RPC port is used by BOINC to communicate between its parts. Not just between boinc and boincmgr, but also between boinc and boinccmd. So, can you run boinccmd after you did boinc --no_gui_rpc?

Explain to me why I've never been able to run the BM when there is a password in the gui_rpc_auth.cfg [think I'm repeating]. Remove the password again by editing the file, restart BOINC and the BM connects without a wrong password warning.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

Explain to me why I've never been able to run the BM when there is a password in the gui_rpc_auth.cfg [think I'm repeating]. Remove the password again by editing the file, restart BOINC and the BM connects without a wrong password warning.

Would be nice if you cut the quote down to the part where you answer, but alas.

But to answer you, uhm, I cannot explain it. Until you said something about it in a previous post, I didn't even know that you needed to do that. I suppose it works differently on Linux. That's why I put it in front of the developers. Who haven't come back to me yet.

---

Explain to me why I've never been able to run the BM when there is a password in the gui_rpc_auth.cfg [think I'm repeating]. Remove the password again by editing the file, restart BOINC and the BM connects without a wrong password warning.

Would be nice if you cut the quote down to the part where you answer, but alas.

But to answer you, uhm, I cannot explain it. Until you said something about it in a previous post, I didn't even know that you needed to do that. I suppose it works differently on Linux. That's why I put it in front of the developers. Who haven't come back to me yet.

I think, on Windows, I've occasionally seen a 'wrong password' popup dialog when there's actually nothing wrong with the installation, configuration or anything. Try again a few seconds later, and it works.

My working assumption is: based on other observations, some project applications go through a heavy start-up phase when called upon by the BOINC client. Einstein gravity wave and CPDN seem to be particular cases in point. When the core client starts one of these apps, it becomes unresponsive for a few seconds, until whatever heavy work the app has to do is finished, and it has settled into normal crunching (in the Einstein case, the workload seems to be loading and possibly decompressing several large binary data files).

It seems to me that if the Manager attempts to connect with the core client during this unresponsive phase, then 'wrong password' is at least one possible response, where 'client busy' might be a more accurate description.

Suggestions:

1) code-walk the source to see if 'wrong password' requires an actual message to that effect from the client, and isn't just a catch-all last chance 'oops, something went wrong' type of message.

2) try your damnedest to watch the behaviour, activity, and CPU usage of the core client, while trying to start the Manager and connect to said client. See if BM has any more luck connecting after the client has been running a little while.

Frankly, I´ve no idea what the difficulty is in what I explained. It´s -not- anything to do with system busy. It's as simple as -with- a password in the file the connection fails, -without- password in the file the connection succeeds immediately. This is to include with the BOINCTUI 'text only' interface, how light do we want it to be, and BT from remote.

Maybe next time I'm near the Linux box, I'll put a password in, restart client and try boinccmd commands.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

And now that the developers have come back to me, there's plenty more questions. They say that, yes, the gui_rpc_auth.cfg file does contain a password, that it's generated by BOINC at first start-up, that it's a 32 character random password, that it's unique for each user and that if the users wanted to change it, he can do so (with BOINC not running).

Nothing we didn't know before. But for that there's no answer as to why (some) Linux don't use this password then. Rob, do you use Berkeley BOINC, or repository BOINC? And it's Ubuntu, you say? Which version?

---

Thanks, I changed permission of all files in /var/lib/boinc-client/ to 777 but still no luck :(

On both Ubuntu and on Fedora 17 there needs to be a boinc user and group.

On Ubuntu:

/var/lib/boinc-client and subs need to be owned by boinc:boinc

directory/file permissions are not 777 but 644 or 771. I cannot list all the files and permissions here.

I read the installation instructions you followed. I would think it would be a fairly direct install and that in the process correct file permissions and ownership would be established correctly. They are almost the same as for Ubuntu's boinc.

as for the gui_rpc_auth.cfg file mine is empty on Ubuntu. It resides in:
/etc/boinc-client/gui_rpc_auth.cfg

and there is a softlink:

/var/lib/boinc-client/gui_rpc_auth.cfg -> /etc/boinc-client/gui_rpc_auth.cfg

---

www.usefulramblings.org

Frankly, I´ve no idea what the difficulty is in what I explained. It´s -not- anything to do with system busy. It's as simple as -with- a password in the file the connection fails, -without- password in the file the connection succeeds immediately. This is to include with the BOINCTUI 'text only' interface, how light do we want it to be, and BT from remote.

Maybe next time I'm near the Linux box, I'll put a password in, restart client and try boinccmd commands.

This problem has been discussed numerous times. It was even documented in the official BOINC wiki but the cause of the problem and solution(s) were deemed by Eric Meyers to be much too difficult for anyone but him to understand so he removed that content. Y'all might want to send him a 'thank you' for his 'bliss through ignorance' program.

The correct and successful chain of events is:

1. BOINC client starts and looks for a password in gui_rpc_auth.cfg. If it is blank then the client assumes user does not want to use a password and client will then accept a connection from BM even if BM does not present a password. If the file contains a non-blank password then client will allow BM to connect only if BM presents the password.

2. Now user starts BM. If BM sees a GUI_rpc_auth.cfg it will read the password and present that password to BM.

Now here is where you need to stop and THINK. If client reads 'lemmeein' from GUI_RPC_auth.cfg but BM is unable to locate/see/access GUI_RPC_with.cfg then there isn't much chance of BM providing the required password to the client. Right?

Now let's look at how different installers work and hopefully gain further insight.

If you install BOINC on Linux via the Berkeley installer then you own all the files used by the client as well as files used by BM therefore nearly every imaginable permissions problem is eliminated unless you go mucking about with said permissions blindly in the hope that you will get lucky and fix whatever is broken. Also, Berkeley installer will install everything (the binaries plus config files) in one directory which eliminates other problem scenarios. The result is that unless you muck around with the installation, client an BM will most assuredly were and read the same GUI_RPC_with.cfg. That guarantees BM will always know the correct password, regardless of whether that password is blank or not.

Unfortunately, the Berkeley installer does not provide binaries that execute
properly on every distro so many of us turn to the BOINC installer provided by
our favorite distro. And then we run into problems with BM not connecting to client due 'incorrect pasword'. The reason why the problem occurs is very simple in most cases: BM cannot find the GUI_RPC_auth.cfg the client obtained the password from therefore BM can never know the required password UNLESS THE PASSWORD IS BLANK WHICH MEANS THE CLIENT WON'T REQUIRE A PASSWORD.

At this point you should understand why the problem occurs. If not then re-read the above and/or ask quetions until you 'get it'.

Now the moment you've all been waiting for... the fix. The solution. The magic/mojo/juju. The end to all of your BOINC on Linux password frustrations. Drumroll and fanfare please....


Tadaaaaaaa baduptaduptaduptadup taduptadpdadaaaaaaaaaa (insert ttthundering tympanihere) BOM bom BOM bom BOM bom BOM bom BOOOOOOOMMMMMMMMM....

...in your home directory create a link to gui_rpc_auth.cfg and set the permission on the original gui_rpc_auth.cfg to allow all users to read it but not write to it.

At this point the Linux savvy might think like... 'Doesn't that allow any user to connect BM to the client and add/delete projects? The answer of course is 'No'. Only users who have a link to the original GUI_RPC_auth.cfg in their home directory will bee able to connect. If superuser/admindoes not create that link for them then they will never have the link and thus no BM they can ever invoke can ever know the password. Linux... beautifully simple, simply beautiful.

And that's all I have to say about that. The advice presented works on my Linux boxes as well as hundreds of others. If it doesn't work for you then you have some other thing screwed up or you did not implement the advice correctly which is entirely possible since I don't explain it very well.

I neglected to provide some details relevant to the material in the following paragraph from my previous post.

Unfortunately, the Berkeley installer does not provide binaries that execute properly on every distro so many of us turn to the BOINC installer provided by our favorite distro. And then we run into problems with BM not connecting to client due 'incorrect pasword'. The reason why the problem occurs is very simple in most cases: BM cannot find the GUI_RPC_auth.cfg the client obtained the password from...

The above paragraph begs the question "Why can't BM find gui_rpc_auth.cfg? If the client can find gui_rpc_auth.cfg then BM should be able to find it too, no?" The answer is that the installers from repos install the client as a daemon service according to the System V protocol. That protocol includes specs for the configuration files requirede by the client. Those config files tell the client where to store gui_rpc_auth.cfg but unfortunately BM is not allowed access to the client's config files for security considerations.