Started two QC Wu's simultaneously using app version 3.20 and one failed with this stderr report:

<core_client_version>7.9.3</core_client_version>
<![CDATA[
<message>
process exited with code 195 (0xc3, -61)</message>
<stderr_txt>
13:45:21 (5569): wrapper (7.7.26016): starting
13:45:21 (5569): wrapper (7.7.26016): starting
13:45:21 (5569): wrapper: running /bin/bash (-c "flock /var/lib/boinc/projects/www.gpugrid.net/miniconda.lock ./miniconda-installer.sh -b -u -p /var/lib/boinc/projects/www.gpugrid.net/miniconda")
flock: failed to execute ./miniconda-installer.sh: Text file busy
13:45:30 (5569): /bin/bash exited; CPU time 0.000265
13:45:30 (5569): app exit status: 0x45
13:45:30 (5569): called boinc_finish(195)

</stderr_txt>
]]>

Machine is an AMD FX8350 at 4.1 GHz with Fedora 28 kernel 4.16.13 with both gcc and glibc-devel installed.

I had been running both my 8 core machines in 4 core mode and 2 concurrent QC WU's for several months with only one simultaneous start error the whole time but with no other project to compete for the CPU. I found that when running both WCG and QC CPU WU's, simultaneous starts occurred more frequently and unfortunately when it did happen, then failures would leap frog through the queue quickly and blacklist the computer from more work for a day.

Yes, now simultaneous starts crash with "text file busy". Will look for yet another workaround.

Attempting fix at version 321

Just got a couple of errors from last night's WUs version 3.20.

Here are the links:
https://www.gpugrid.net/result.php?resultid=17740487
https://www.gpugrid.net/result.php?resultid=17740592

All the rest ran fine.

^^ These seem connection errors (network down or so)

^^ These seem connection errors (network down or so)

Network can affect computation after the WU is already downloaded?

I have exactly the same problems so I dont think this is connection related.

Version 321 looks promising. Just finished two that started at the same time and they finished normally. Just started three at the same time and they are all processing as they should.

Success with two QC WU's simultaneous start using app 3.21. Both WU's happily crunching @ 1.098% completed so far.

Event Log Excerpt:

Thu 07 Jun 2018 07:22:04 AM MST | GPUGRID | task m0000000638_2278bdac_n00020-SDOERR_QMML50-0-1-RND5957_0 resumed by user
Thu 07 Jun 2018 07:22:04 AM MST | GPUGRID | task m0000000643_5ed133e9_n00020-SDOERR_QMML50-0-1-RND3172_0 resumed by user
Thu 07 Jun 2018 07:22:05 AM MST | GPUGRID | Starting task m0000000638_2278bdac_n00020-SDOERR_QMML50-0-1-RND5957_0
Thu 07 Jun 2018 07:22:05 AM MST | GPUGRID | Starting task m0000000643_5ed133e9_n00020-SDOERR_QMML50-0-1-RND3172_0

^^ These seem connection errors (network down or so)

Network can affect computation after the WU is already downloaded?

Yes. WUs check the latest version of conda packages/libraries right after start (from conda cloud).

^^ These seem connection errors (network down or so)

Network can affect computation after the WU is already downloaded?

Yes. WUs check the latest version of conda packages/libraries right after start (from conda cloud).

Dang is that only after start? If tasks were started, paused, another started, etc could networking be disabled after they start? Or at each start/resume? Not me, but I've heard of some setup schedules to allow downloads at certain times of the day due to varying bandwidth costs.

Today I have had three successful simultaneous starts and returns without error on two different FX8350 machines. As far as I am concerned, this bug has been resolved at least for the Fedora distro.

Haven't gotten a single error with version 3.21 and it's been running all day. What did you change?

The main change was locking the miniconda directory upon initial installation/update. This in turn required some workarounds. May not be perfect but should be much better.

Regarding network access, it is attempted at each WU start or re-start. The amount of downloaded data should be usually negligible (except the first time).

Edit to add: the network accesses are only to "conda cloud", a python distribution and package manager.

No more error, but a strange behaviour.
Remanining time for every wus are over 20h, but wus are crunched in 40/50 minutes...

Didn't get any response from my post in the cpu tasks thread.

How do you get the cpu tasks? I tried and failed. Is the QC app still considered a Test app? That was the only Preference toggle I didn't select.

Did you check: use CPU as well? You might not have allowed it.

No it is not necessary to check BETA tasks. I do not have checked it either, but I do get QC tasks.

Yes CPU was checked for use both places and the QC app. Didn't get any QC tasks both time I tried. Just gpu tasks. The scheduler request was for both cpu and gpu work. I know there is plenty of cpu tasks to farm out. Couldn't explain why I didn't get any work. I'll have to try again without gpu work checked I guess.

Yes CPU was checked for use both places and the QC app. Didn't get any QC tasks both time I tried. Just gpu tasks.

That is your problem. The BOINC scheduler can get all mixed up when you select both CPU and GPU work on the same project, and you are eventually left high and dry on one or the other.

There are several discussions on it at Einstein, which has the same problem since they do both CPU and GPU work. Here is one recent discussion, where the moderator explains why the requester is not getting GPU work.
https://einsteinathome.org/content/not-getting-gpu-wus-anymore#comment-165295

I use separate machines for the CPU work and the GPU work on GPUGrid.

Thanks for the reply. I don't know. It worked a couple of months ago when the QC app and tasks first showed up. I was crunching both gpu and cpu at the same time. I know that shutting off a gpu request will probably work just to get some of the new QC tasks along with the latest 3.21 app.

I was just wondering how well the app works now with concurrent starts.