boinc might use /home

Bug #402082 reported by dino99
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
boinc (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: boinc

hi,
here is my config:
- i have boinc installed on Jaunty partition sdc2
- my /home is on a dedicated partition sda3
- karmic is installed on sdc5

Now my question:
If i install boinc on sdc5 (karmic), why i cant continue working on the current job load with Jaunty boinc ? i dont understand this as the 2 os have the same /home.

It's very frustating when apps dont use /home by default: is it a design problem, a misconfiguration ?
How can i set boinc configuration to use /home by default ?

dino99 (9d9)
description: updated
Revision history for this message
rww (rww-deactivatedaccount) wrote :

The BOINC packages are currently configured on a per-computer basis, not a per-user basis. This has several advantages:

* the BOINC client can do work while nobody's logged in
* more than one user can control the BOINC instance, as the files are owned by a BOINC user and group
* usually, people don't want to have different configurations for different users

Per-computer files are supposed to be stored in /var/lib/. Doing what BOINC does on Windows and making a home folder for the BOINC user in /home/ doesn't seem to be the done thing in Debian-based distros.

Even in situations, like yours, where putting them in /home seems to make sense, there are potential problems. Jaunty and Karmic's BOINC packages are different versions, and using the same configuration files for those two versions is probably not a great idea.

For your particular situation, I'd recommend using the upstream .sh version at http://boinc.berkeley.edu/download_all.php, rather than Ubuntu's packages. If you run that inside your home directory, it'll install BOINC there, and you can run the binaries it creates from either karmic or jaunty. That way, you'd be using the same version (in fact, the same binaries), and shouldn't have problems. However, since you wouldn't be using Ubuntu packages in this case, it's rather outside the scope of this venue...

Revision history for this message
dino99 (9d9) wrote :

Many thanks Robert for all those explanations, very clear & usefull.
What i meant in my first question, is only about the job project (for example: wgc) . I know about the difference in Jaunty & karmic packages, but what's about the download computed projects ? i continue to think that should be done by any os if that work projects was computed into /home instead /var/lib/ .
The reason why i ask about that: if one of the installed os fail, instead of loosing the actual job work, the other os can continue the same jobs instead of downloading new ones.

Hope you understand & see the advantages.

Revision history for this message
Steffen Möller (moeller-debian) wrote : Re: [Bug 402082] Re: boinc might use /home

Hello,

dino99 wrote:
> What i meant in my first question, is only about the job project (for example: wgc) . I know about the difference in Jaunty & karmic packages, but what's about the download computed projects ? i continue to think that should be done by any os if that work projects was computed into /home instead /var/lib/ .
> The reason why i ask about that: if one of the installed os fail, instead of loosing the actual job work, the other os can continue the same jobs instead of downloading new ones.
>
with how many computer do you share your home directory?

As long as BOINC can rest assured that the executing boinc-client knows
exactly who is using the BOINC home folder - itself only, it does not
need to fight any competitors who otherwise might want to continue a
result file that is currently being worked on. And flagging a workunit
is not sufficient since the file may be leftover from some system crash.

Yes, there are means to circumvent such issues, but this will render the
software more complicated. I can even presume that BOINC does it all
already, though. Even if your workunit could be shared between work and
home and as such be completed earlier - you can almost same as well have
one workunit worked at at home and suspend that until you are home again.

We should leave things as simple as possible. And if you lose the one or
other workunit, or if it comes in later than the deadline - well - in my
mind this does matter so much. Also, I don't think that multiple
applications should work on the same workunit since it then is unclear
in case of a later identified error which workunits should be
investigated again.

Best,

Steffen (who is also with WCG and redid 12 old (5 days overdue) FAAH
WUs for which he truly did not receive any credits)

Revision history for this message
dino99 (9d9) wrote :

thanks for reply Steffen,

i agree with you when you says : "We should leave things as simple as possible".
As i've described my config on the first post, i run boinc on 1 computer with dual boot, no network or things complicated here. What i wish is that apps path workunit can be costumized by user to use /home for the reasons i've explained previously, that seem more logical & cant see the difficulties to do that.

Revision history for this message
Frank S. Thomas (fst) wrote :

On Wednesday 22 July 2009 07:37:24 dino99 wrote:
> What i wish
> is that apps path workunit can be costumized by user to use /home for the
> reasons i've explained previously, that seem more logical & cant see the
> difficulties to do that.

You should read the fine manual /usr/share/doc/boinc-client/README.Debian and
after that have a look at /etc/default/boinc-client, and change BOINC_DIR to
your liking.

Revision history for this message
Steffen Möller (moeller-debian) wrote :

Frank S. Thomas wrote:
> On Wednesday 22 July 2009 07:37:24 dino99 wrote:
>
>> What i wish
>> is that apps path workunit can be costumized by user to use /home for the
>> reasons i've explained previously, that seem more logical & cant see the
>> difficulties to do that.
>>
>
> You should read the fine manual /usr/share/doc/boinc-client/README.Debian and
> after that have a look at /etc/default/boinc-client, and change BOINC_DIR to
> your liking.
>

Many thanks, Thomas, I have just reread dino99's original message, I
should have indicated that, too. Somehow I had dual boot associated with
Windows/Linux, not karmic/jaunty, so I concur that the change to /home
might indeed work if the apps are indistinguishable. Also I had
understood that multiple apps would work concurrently on that directory,
which apparently is not the case.

dino99, please be so kind to drop us a not stating if it has worked.

Another possibility, possibly preferable because of the physical
identity of the applications, might be to mount the var/lib/boinc-client
directory from the first into the second OS.

Cheers,

Steffen

Revision history for this message
dino99 (9d9) wrote :

Many thanks Frank & Steffen,

I just read your responses and i'll give back here in 1 or 2 days my experience.
I'm very sorry to never think about the hidden README files, but i hope future brinks more custom settings in all that apps wich ignore /home when doing the job.

Revision history for this message
dino99 (9d9) wrote :

hi,

Some feedback about Boinc_dir:

I've done it & that work fine.
1) stop receiving new workunits
2) wait for loading the least job
3) change boinc_dir (/etc/default/boinc-client)
4) stop boinc
5) sudo cp -R -p /var/lib/boinc-client /home/oem/boinc-client
       (- R for folder & subfolders, -p to preserve owner, group & rights)
6) sudo dpkg-reconfigure boinc-client
7) close & reboot on the other os: job continue to be done on the previous workunits'os job downloaded.

That it: receiving, computing & sending workunits run without problem.
* changes made on each boinc installation of course.

So, i hope devs follow my ideas & provide settings to customize installation.

Revision history for this message
Steffen Möller (moeller-debian) wrote :

Have many thanks, Dino!

Steffen

Changed in boinc (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.