I just did a Linux upgrade and WUProp failed and WUProp packets kept failing.

<core_client_version>7.2.42</core_client_version>
<![CDATA[
<message>
process exited with code 8 (0x8, -248)
</message>
<stderr_txt>
Process creation (../../projects/wuprop.boinc-af.org/data_collect_v4_418_i686-pc-linux-gnu__nci) failed: Error -1, errno=8
execv: Exec format error

</stderr_txt>
]]>

But now I get "This computer has finished a daily quota of 2 tasks". I'm sure it'll be OK tomorrow, I was just surprised to see there is a quota.

Resetting the project has made no difference.

I was getting:

Fri 13 Mar 2015 08:28:56 GMT | WUProp@Home | Output file data_collect_v4_1426193401_1730_0_0 for task data_collect_v4_1426193401_1730_0 absent

Now it is just:

Fri 13 Mar 2015 08:51:42 GMT | WUProp@Home | This computer has finished a daily quota of 1 tasks

The problem is a path error in v4.18

Process creation (../../projects/wuprop.boinc-af.org/data_collect_v4_418_i686-pc-linux-gnu__nci) failed: Error -1, errno=8
execv: Exec format error

I have no /projects/wuprop.boinc-af.org/

On this Linux Xubuntu PC it is installed elsewhere:

$ locate wuprop.boinc-af.org
/var/lib/boinc-client/account_wuprop.boinc-af.org.xml
/var/lib/boinc-client/job_log_wuprop.boinc-af.org.txt
/var/lib/boinc-client/master_wuprop.boinc-af.org.xml
/var/lib/boinc-client/sched_reply_wuprop.boinc-af.org.xml
/var/lib/boinc-client/sched_request_wuprop.boinc-af.org.xml
/var/lib/boinc-client/statistics_wuprop.boinc-af.org.xml

Ignore me. I'm an idiot.

$ sudo locate wuprop.boinc-af.org
/var/lib/boinc-client/account_wuprop.boinc-af.org.xml
/var/lib/boinc-client/job_log_wuprop.boinc-af.org.txt
/var/lib/boinc-client/master_wuprop.boinc-af.org.xml
/var/lib/boinc-client/sched_reply_wuprop.boinc-af.org.xml
/var/lib/boinc-client/sched_request_wuprop.boinc-af.org.xml
/var/lib/boinc-client/statistics_wuprop.boinc-af.org.xml
/var/lib/boinc-client/notices/archive_wuprop.boinc-af.org_notices.py.xml
/var/lib/boinc-client/notices/feeds_wuprop.boinc-af.org.xml
/var/lib/boinc-client/notices/wuprop.boinc-af.org_notices.py.xml
/var/lib/boinc-client/projects/wuprop.boinc-af.org
/var/lib/boinc-client/projects/wuprop.boinc-af.org/cache

However,

$ sudo ls -la /var/lib/boinc-client/projects/wuprop.boinc-af.org
total 44
drwxrwx--x 2 boinc boinc 4096 Mar 13 08:48 .
drwxrwx--x 18 boinc boinc 4096 Jan 13 12:43 ..
-rw-r--r-- 1 boinc boinc 33280 Mar 13 07:26 cache

Shouldn't there be a data_collect_v4_418_i686-pc-linux-gnu__nci in there?

All four of my ubuntu 14.04 boxes started throwing this error since the early hours of the morning. One was rebuilt last night the other three have not been touched for a week or two, so doubt the update of Linux has anything to do with it. Windows is unaffected.

What do you have in /var/lib/boinc-client/projects/wuprop.boinc-af.org ?

On the PC that is failing, there is just 'cache'.


On another PC that is working (Xubuntu 14.04.2) there is:

# sudo ls -la /var/lib/boinc-client/projects/wuprop.boinc-af.org
total 1696
drwxrwx--x 2 boinc boinc 4096 Mar 13 11:53 .
drwxrwx--x 19 boinc boinc 4096 Jan 11 22:18 ..
-rw-r--r-- 1 boinc boinc 21030 Mar 13 13:03 cache
-rwxr-xr-x 1 boinc boinc 812136 Jul 1 2013 data_collect_v3_3.52_x86_64-pc-linux-gnu__nci
-rw-r--r-- 1 boinc boinc 22029 Mar 13 13:03 data_collect_v4_1426193401_8661_0_0
-rwxr-xr-x 1 boinc boinc 851997 Mar 13 11:53 data_collect_v4_418_x86_64-pc-linux-gnu__nci

so it may only be 32-bit PCs that are failing.

I'll have to go and check but for me the 4v4.15 worked perfectly. As soon as I got 4v4.18 units they all fail both on 32 bit and 64 bit versions.
The
Stderr output

<core_client_version>7.4.23</core_client_version>
<![CDATA[
<message>
process exited with code 127 (0x7f, -129)
</message>
<stderr_txt>
../../projects/wuprop.boinc-af.org/data_collect_v4_418_x86_64-pc-linux-gnu__nci: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

</stderr_txt>
]]>

I guess the app has a broken link to libstdc++.so.6 as that is installed on all my systems.

http://wuprop.boinc-af.org/result.php?resultid=47918633

Getting it also on Slackware 64. Started about 13 Mar 2015, 12:31:19 UTC or so. Above link is the earliest that I can find. WinDoze boxes no problem so far. The are Windoze 8.1.

Donn

I started seeing this as of 12 hours or so ago as well on one of my Ubuntu boxes as well as a Fedora 21 machine. Nothing has changed on these boxes in the last week with respect to Linux updates or BOINC changes.

Other clients (mostly Windows) that are running WUProp have not had this issue. Other projects are running successfully on all these boxes.

Mark

The Data Collect version 4 application was updated to v4.18 at 6:36 this morning. Link: Applications.

I'm wondering why my Xubuntu box is managing to process a v4.18 packet.

I'm wondering why my Xubuntu box is managing to process a v4.18 packet.

If it is a 64-bit distro with 32-bit libraries installed it will probably work as the 64-bit executable is really 32-bits.

It is indeed a 64-bit distro with 32-bit libraries installed in addition.

So the 32-bit app is the 64 bit app, and the 64 bit app is the 32 bit app? Oops! :-D

So presumably, if one downloads

http://wuprop.boinc-af.org/download/data_collect_v4_418_i686-pc-linux-gnu__nci

into

/var/lib/boinc-client/projects/wuprop.boinc-af.org

and uses it to overwrite data_collect_v4_418_x86_64-pc-linux-gnu__nc (or vice versa as appropriate), it might work?

So presumably, if one downloads

http://wuprop.boinc-af.org/download/data_collect_v4_418_i686-pc-linux-gnu__nci

into

/var/lib/boinc-client/projects/wuprop.boinc-af.org

and uses it to overwrite data_collect_v4_418_x86_64-pc-linux-gnu__nc (or vice versa as appropriate), it might work?

Not sure. It would have to be renamed to x86_64 after the download/copy and if the project checks for MD5 or CRC32 it may fail as that would not match what is in the client_state.xml file.

I'll give it a try and report back in a few minutes.

Edit: That appears to work. I downloaded the file labeled as 32-bit, renamed it to the 64-bit name, ran ldd and file to check it (everything looked ok) and it has been running for 3 minutes. Will have to wait for 6 hours to see if it finished correctly and verifies.

I was also able to get one of my machines to run a WU by swapping 32/64-bit executables. The other machine has hit it's daily limit and refuses to download another WU, but that will probably reset at 00:00 UTC later today.

My third Linux box continues to run, probably because it has the 32-bit libraries installed.

Mark

Looks like the Linux Apps has been updated which seems to have fixed the problem, my Linux vm has gotten a new WU which seems to be working fine.

Now if we could just get the additional badge sets life would be good.

Thanks Sebastien for all your hard work...

---

Woot! Indeed, v4.19 (32 bit) has been running on this PC for 49 minutes. :-)

Where in the commercial software sector could you get this kind of user diagnosis and prompt supplier fix?

Woot! Indeed, v4.19 (32 bit) has been running on this PC for 49 minutes. :-)

Where in the commercial software sector could you get this kind of user diagnosis and prompt supplier fix?

That's why we are called volunteers and not customers :)

The Win app got an update from v4.15 to v4.18.

Someone know why, what's new?

Thanks.

---