> Just delete this file then you'll be able to start it again.
You were right about the lockfile. I deleted it from the boinc directory and now my client asks me to set up the project once again and is telling me that the host ID is not assigned at all. You might as well have said 'to start all over again'. :-(
If it had worked for you, then it's okay. On my machine this has caused a bigger mess, however. Sorry.
Have tried to reset project but still it fails to do anything. Now I continously get 'init_op_project failed, error -108' . But no worries, I just wacked my machine out of the window, fetched the pieces, applied some super glue and now it's crunching from scratch - d'oh!
But these are the pains we all love, inni't? ;-)
:
your thoughts - the ways :: the knowledge - your space
:
> You were right about the lockfile. I deleted it from the boinc directory and
> now my client asks me to set up the project once again and is telling me that
> the host ID is not assigned at all. You might as well have said 'to start all
> over again'. :-(
>
> If it had worked for you, then it's okay. On my machine this has caused a
> bigger mess, however. Sorry.
Actually, you're having to start it over again because you ran it as root. Running it as root will re-assign all the dynamic files to root priviledges only (all your account data files and the work unit files). Once you go up to root, any file that updates or any new work units that download while it's running as root will only have priviledges for root, so moving back down and running it as a regular user again means the regular user no longer has access to them.
That will happen anytime you run it as root for any reason. If you're comfortable with terminal commands (specifically "chown"), it is possible to recursively chown all the files back to your regular user account after running it as root.
Intermittently not releasing the lockfile has been an issue with boinc since it was in beta. Deleting it has no effect on the other files. Boinc creates it when it starts (it's just an empty file named "lockfile") so that it knows it's running. When you tell it to start, it looks for this file - if it finds it it thinks it's already running, if it doesn't find it it starts up and creates it so that it knows it's running. It should release it when it shuts down, but it doesn't always.
If it happens again and you delete the lockfile without ever running it as root, your priviledges won't get changed and you'll start back right where you left off.
> Actually, you're having to start it over again because you ran it as root.
Thanks for telling me now!:-D
Now that it runs, I rather wait until the next time the error pops up. I am not too comfortable with the terminal just yet, but I guess, I have to get used to it anyways.
In the end, you were right about the lockfile; it's what caused this problem to appear in my case. Thanks for explaining how root VS user relates. I will watch out the next time (or at least, I will try hard!)
> If it happens again and you delete the lockfile without ever running it as
> root, your priviledges won't get changed and you'll start back right where you
> left off.
I'll keep that in mind. Thanks once again!
:
your thoughts - the ways :: the knowledge - your space
:
Sounds like you got it working. I received the same error and I think it may be helpful for others to know this information.
"another instance of boinc is running" may be caused by permissions problems on your BOINC directory. If you executed boinc_xxx-linux-gnu.sh as root (say "sudo sh boinc_xxx-linux-gnu.sh") the BOINC directory is owned by root. When you try to start boinc as a normal user, boinc cannot create the lockfile and complains (incorrectly) about another instance running.
The fix is easy. One directory above BOINC (probably your home folder) execute:
sudo chown -R your_user BOINC
replacing your_user with the appropriate value
I was actually brilliant enough to create a boinc user (to daemonize boinc) and gave root ownership of boinc's working directory. I ended up having to chown /var/lib/boinc (I opted against the standard /home/boinc).
> Just delete this file then
)
> Just delete this file then you'll be able to start it again.
You were right about the lockfile. I deleted it from the boinc directory and now my client asks me to set up the project once again and is telling me that the host ID is not assigned at all. You might as well have said 'to start all over again'. :-(
If it had worked for you, then it's okay. On my machine this has caused a bigger mess, however. Sorry.
Have tried to reset project but still it fails to do anything. Now I continously get 'init_op_project failed, error -108' . But no worries, I just wacked my machine out of the window, fetched the pieces, applied some super glue and now it's crunching from scratch - d'oh!
But these are the pains we all love, inni't? ;-)
:
your thoughts - the ways :: the knowledge - your space
:
> You were right about the
)
> You were right about the lockfile. I deleted it from the boinc directory and
> now my client asks me to set up the project once again and is telling me that
> the host ID is not assigned at all. You might as well have said 'to start all
> over again'. :-(
>
> If it had worked for you, then it's okay. On my machine this has caused a
> bigger mess, however. Sorry.
Actually, you're having to start it over again because you ran it as root. Running it as root will re-assign all the dynamic files to root priviledges only (all your account data files and the work unit files). Once you go up to root, any file that updates or any new work units that download while it's running as root will only have priviledges for root, so moving back down and running it as a regular user again means the regular user no longer has access to them.
That will happen anytime you run it as root for any reason. If you're comfortable with terminal commands (specifically "chown"), it is possible to recursively chown all the files back to your regular user account after running it as root.
Intermittently not releasing the lockfile has been an issue with boinc since it was in beta. Deleting it has no effect on the other files. Boinc creates it when it starts (it's just an empty file named "lockfile") so that it knows it's running. When you tell it to start, it looks for this file - if it finds it it thinks it's already running, if it doesn't find it it starts up and creates it so that it knows it's running. It should release it when it shuts down, but it doesn't always.
If it happens again and you delete the lockfile without ever running it as root, your priviledges won't get changed and you'll start back right where you left off.
> Actually, you're having to
)
> Actually, you're having to start it over again because you ran it as root.
Thanks for telling me now!:-D
Now that it runs, I rather wait until the next time the error pops up. I am not too comfortable with the terminal just yet, but I guess, I have to get used to it anyways.
In the end, you were right about the lockfile; it's what caused this problem to appear in my case. Thanks for explaining how root VS user relates. I will watch out the next time (or at least, I will try hard!)
> If it happens again and you delete the lockfile without ever running it as
> root, your priviledges won't get changed and you'll start back right where you
> left off.
I'll keep that in mind. Thanks once again!
:
your thoughts - the ways :: the knowledge - your space
:
Sounds like you got it
)
Sounds like you got it working. I received the same error and I think it may be helpful for others to know this information.
"another instance of boinc is running" may be caused by permissions problems on your BOINC directory. If you executed boinc_xxx-linux-gnu.sh as root (say "sudo sh boinc_xxx-linux-gnu.sh") the BOINC directory is owned by root. When you try to start boinc as a normal user, boinc cannot create the lockfile and complains (incorrectly) about another instance running.
The fix is easy. One directory above BOINC (probably your home folder) execute:
sudo chown -R your_user BOINC
replacing your_user with the appropriate value
I was actually brilliant enough to create a boinc user (to daemonize boinc) and gave root ownership of boinc's working directory. I ended up having to chown /var/lib/boinc (I opted against the standard /home/boinc).