Hi there,
this two posts describe the same error in BOINC, with no real answer to 
it up to now.

This one:
http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2011-November/016105.htmlDate:
 
Sun, 13 Nov 2011 17:10:31 -0000 :
> From: "Richard Haselgrove"<r.haselgrove_at_btinternet.com>
> Subject: [boinc_alpha] Misleading file upload error (persistent
>       transfer)
> To:<boinc_alpha_at_ssl.berkeley.edu>
> Message-ID:<8F66EA8D25BE4053BCDD882C8F811B32@ANONYMOUS>
> Content-Type: text/plain;     charset="iso-8859-1"
>
> I've been wrestling since yesterday with
>
> 13/11/2011 12:18:22 | NumberFields@home | [fxd] starting upload, 
> upload_offset 0
> 13/11/2011 12:18:22 | NumberFields@home | [file_xfer] Couldn't start upload 
> of wu_12E10_SF157-1_Idx9_Grp21649of57133_0_0
> 13/11/2011 12:18:22 | NumberFields@home | [file_xfer] URL 
> http://NumberFields.asu.edu/NumberFields_cgi/file_upload_handler/: not found
> 13/11/2011 12:18:22 | NumberFields@home | Backing off 7 hr 35 min 20 sec on 
> upload of wu_12E10_SF157-1_Idx9_Grp21649of57133_0_0
>
> which appears to be 'url not found' - a server or dns problem. Yet other 
> uploads to NF@h were going through OK from the same machine. The problem 
> started under v6.13.10, and continued after upgrade to v6.13.12 - Windows 7, 
> 64-bit version. This seems to be a similar event to one currently under 
> investigation at Einstein: 
> http://einstein.phys.uwm.edu/forum_thread.php?id=9168
>
> Looking in stddaeout.txt gave one more line than the Manager's event log did:
>
> 13-Nov-2011 12:18:22 [NumberFields@home] [fxd] starting upload, upload_offset > 0
> HTTP::init_post2: couldn't get file size
> 13-Nov-2011 12:18:22 [NumberFields@home] [file_xfer] Couldn't start upload of 
> wu_12E10_SF157-1_Idx9_Grp21649of57133_0_0
> 13-Nov-2011 12:18:22 [NumberFields@home] [file_xfer] URL 
> http://NumberFields.asu.edu/NumberFields_cgi/file_upload_handler/: not found
> 13-Nov-2011 12:18:22 [NumberFields@home] Backing off 7 hr 35 min 20 sec on 
> upload of wu_12E10_SF157-1_Idx9_Grp21649of57133_0_0
>
> Looking back through the logs, I found
>
> 12-Nov-2011 19:08:50 [---] file 
> projects/numberfields.asu.edu_NumberFields/wu_12E10_SF157-1_Idx9_Grp21649of57133_0_0
>  not found
>
> as part of a v6.13.10 startup sequence, but there was no matching line 
> following the upgrade to v6.13.12
>
> It looks as if the file had been uploaded properly at the first attempt:
>
> 12-Nov-2011 19:02:24 [NumberFields@home] Starting task 
> wu_12E10_SF157-1_Idx9_Grp21649of57133_0 using GetBoundedDecics version 202
> 12-Nov-2011 19:02:27 [NumberFields@home] Computation for task 
> wu_12E10_SF157-1_Idx9_Grp21649of57133_0 finished
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] HTTP_OP::libcurl_exec(): 
> ca-bundle 'C:\BOINC\ca-bundle.crt'
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] HTTP_OP::libcurl_exec(): 
> ca-bundle set
> 12-Nov-2011 19:02:28 [NumberFields@home] Started upload of 
> wu_12E10_SF157-1_Idx9_Grp21649of57133_0_0
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Info:  Re-using 
> existing connection! (#0) with host NumberFields.asu.edu
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Info:  Connected to 
> NumberFields.asu.edu (129.219.44.120) port 80 (#0)
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Sent header to 
> server: POST /NumberFields_cgi/file_upload_handler/ HTTP/1.1
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Sent header to 
> server: User-Agent: BOINC client (windows_x86_64 6.13.10)
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Sent header to 
> server: Host: NumberFields.asu.edu
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Sent header to 
> server: Accept: */*
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Sent header to 
> server: Accept-Encoding: deflate, gzip
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Sent header to 
> server: Content-Type: application/x-www-form-urlencoded
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Sent header to 
> server: Content-Length: 702
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Sent header to 
> server:
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Received header 
> from server: HTTP/1.1 200 OK
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Received header 
> from server: Date: Sat, 12 Nov 2011 19:02:41 GMT
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Received header 
> from server: Server: Apache/.2.14 (Ubuntu)
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Received header 
> from server: Vary: Accept-Encoding
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Received header 
> from server: Content-Encoding: gzip
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Received header 
> from server: Content-Length: 60
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Received header 
> from server: Content-Type: text/plain
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Received header 
> from server:
> 12-Nov-2011 19:02:28 [NumberFields@home] [http] [ID#1979] Info:  Connection 
> #0 to host NumberFields.asu.edu left intact
> 12-Nov-2011 19:02:29 [NumberFields@home] Finished upload of 
> wu_12E10_SF157-1_Idx9_Grp21649of57133_0_0
>
> The file was not present in the project folder (BOINC data directory)
>
> After cleaning up client_state.xml, I was able to report the job normally 
> (http://numberfields.asu.edu/NumberFields/result.php?resultid=471210): I'm 
> not certain whether this confirms that the upload file was received correctly 
> by the server, because NF@h only sends a single copy of each WU, and doesn't 
> validate against other users.
>
> Looking at the timestamp of that successful upload, I think that BOINC may 
> have lost DNS and internet connectivity, because I rebooted my router around 
> that time. But I can't explain why an upload which was logged as 'finished' 
> should have turned into
>
> <file>
>      <name>wu_12E10_SF157-1_Idx9_Grp21649of57133_0_0</name>
>      <nbytes>242.000000</nbytes>
>      <max_nbytes>100000000.000000</max_nbytes>
>      <md5_cksum>e9db5f9f481a3417dbb742f1c26325e6</md5_cksum>
>      <status>0</status>
>      
> <upload_url>http://NumberFields.asu.edu/NumberFields_cgi/file_upload_handler/</upload_url>
>      <persistent_file_xfer>
>          <num_retries>22</num_retries>
>          <first_request_time>1321124548.442823</first_request_time>
>          <next_request_time>1321214022.595722</next_request_time>
>          <time_so_far>1.072515</time_so_far>
>          <last_bytes_xferred>306.000000</last_bytes_xferred>
>          <is_upload>1</is_upload>
>      </persistent_file_xfer>
> </file>

and this one:
http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2011-December/018274.html
> Hi there,
>
> I just had problems with a result from Einstein, something had gone
> wrong with the upload. Here's the thread in the forum over there:
> http://einstein.phys.uwm.edu/forum_thread.php?id=9212
>
> Somehow 3 files of one result, which should upload 8 files if done, did
> upload fine, but my machine didn't get it.
> In the client_state.xml they were still marked as <persistent file
> transfer>.
> The logs in my BOINC messages were very misleading, they said that I had
> problems connecting with the file_upload_handler, that the
> file_upload_handler was not to be found.
>
> Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [fxd] starting upload,
> upload_offset 0
> Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [file_xfer] Couldn't start
> upload of p2030.20100614.G46.20-00.29.C.b0s0g0.00000_3344_0_2
> Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [file_xfer] URL
> http://einstein-dl.aei.uni-hannover.de/cgi-bin/file_upload_handler: not
> found
> Do 08 Dez 2011 20:49:55 CET | Einstein@Home | Backing off 7 hr 51 min 19
> sec on upload of p2030.20100614.G46.20-00.29.C.b0s0g0.00000_3344_0_2
>
> Fortunately Richard Haselgrove had the same problem before and knew the
> solution, as cn be seen in the thread over there.
> Gary Roberts suggested a very strange, but somehow probably right,
> interpretation of the log entries:
>> [It] doesn't actually say that a URL wasn't found. I interpret it to
>> mean that the file_upload_handler (whose URL was given) has reported
>> back a 'not found' message for the file that it was told to upload -
>> the file whose name was given in the first line.
>
> If this interpretation is right, which seems to be the case, why is
> there such a misleading message? The message clearly says something's
> wrong on the server side, at least for me. If the files for uploading
> are not on my machine, as they were, it should say something along the
> lines:
> Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [fxd] starting upload,
> upload_offset 0
> Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [file_xfer] Couldn't start
> upload of p2030.20100614.G46.20-00.29.C.b0s0g0.00000_3344_0_2
> Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [file_xfer] File
> p2030.20100614.G46.20-00.29.C.b0s0g0.00000_3344_0_2 was not found on
> your computer
> Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [file_xfer] Please check
> your program folders and client_state.xml for any errors 


_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to