Can't access local boinc client anymore, Authorization failure: -155
12 Jun 2019 19:55:24 UTC
Topic 219029
(moderation:
I have a boinc project folder containing various project data. Usually I started boinc in this folder via the boincmgr using this command line:
boincmgr -e /usr/bin/ -d . &
Suddenly it stopped working, no connection to localhost. Trials with boinccmd in this directory show the error: Authorization failure: -155
In this folder exists a "gui_rpc_auth.cfg". Strangely enough there is a file with the same name in home dir "~/gui_rpc_auth.cfg", both containing different passwords.
If I run boinccmd in the home dir I don't get a error message, but there isn't any useful project information also.
Any ideas?
Regards
Lutz
I believe gui_rpc_auth.cfg
)
I believe gui_rpc_auth.cfg governs some forms of access to your information from another machine on your network (I use it with BoincTasks). I doubt it has anything at all to do with your problem.
Have you considered the possibility of a file permission problem?
In the mentioned project
)
In the mentioned project folder all files are readable and writable by the current user:
E.g.
-rw-r--r-- 1 lutz users 58315 11. Jun 22:32 client_state.xmlThis didn't change. And I start the command as this user.
Lutz Epperlein wrote:I have a
)
You don't say what OS your are using - perhaps Linux or one of the BSDs or some other unix-like one. Your computers are hidden so I can't check for myself. I use Linux and I also use a custom script to launch the client - but not using boincmgr. I'm presuming (but don't know for sure because I've never tried it) that your method launches the manager which in turn launches the client and then attaches to it.
I prefer to launch the client as a daemon (an always running background process) and only ever launch the manager if I want to see what's going on (which is not very often). I do that remotely since most of my machines essentially run headless.
The -e switch to boincmgr sets the clientdir so you have installed the executables under /usr/bin/. The -d switch sets the data directory so the '.' argument means "whatever directory you happen to be in when you launch boincmgr". The fact that you have a gui_rpc_auth.cfg file in your home directory means that at some point you inadvertently issued the launch command when you were in your home directory.
As a result of that, the client must have created a new gui_rpc_auth.cfg file for you and populated it with a 32 char random string (I imagine) :-). There are probably other freshly created files (eg a bare bones state file) as well. Because your home dir is not your correct data dir, your proper state file won't be found there and so the client that starts will have no idea of your projects. I think this is the correct assessment since it seems to fit your description of what you see.
To protect yourself against this in future (and if you want to continue using the same method to launch the client) you should amend your launch script to specify the precise data directory, rather than just using '.'. That way, you won't have to rely on remembering to cd to the correct directory before launching boincmgr.
What I suspect you need to do first is run boinccmd with the --quit option in your home directory where there is no auth failure. That should cause the wrongly launched client to quit. Then you could relaunch boincmgr with the corrected -d option to see if all your project information is back again. If so, you should do a thorough clean-out of your home dir for excess BOINC files created there in error.
Hopefully, that will get things back to normal. Let us know how you go
Cheers,
Gary.
@Gary, thanks for your
)
@Gary, thanks for your comprehensive description, all you said makes sense to me, especially regarding my special environment. And you are right, it is a Linux machine.
And I solved the problem nearly the same way you suggested, quitting the wrong launched client. With the difference that I reboot my machine instead of calling boinccmd --quit.
Thanks again
Lutz
@Lutz, Thanks for letting us
)
@Lutz,
Thanks for letting us know. I'm glad everything is back to normal for you.
Cheers,
Gary.