md5 check failed

Forums › Problems and Bug Reports

Anonymous
21 Aug 2008 9:58:55 UTC
Topic 13699
(moderation:
    )

    Quote:

    Many thanks for the report, I forwarded this to the E@H team.

    CU
    Bikeman

    This is strange. It appears on the server side as if no workunits have ever been generated that require and/or use this file. Could you please give me the NAME of the workunit that uses this file?

    For what it is worth, the file on the server has the same checksum as reported below, and checks as a valid SFT:

    [root@einstein download]# md5sum ./23/l1_0873.00_S5R4
0b35efca8e47808f6b751a8045e7113c  ./23/l1_0873.00_S5R4
    


    [root@einstein download]# ~/sftlib/SFTvalidate ./23/l1_0873.00_S5R4
    
[root@einstein download]#

    Is it possible that the user edited client_state.xml and inadvertently changed the file name?

    Cheers,
    Bruce

    EDIT: What I wrote above was misleading. David Hammer was also working to fix this problem and had deleted the incorrect l1_0873.00_S5R4.md5 file, leading me to believe that no WU had been generated for this data file.

    After searching the database, I found 125 workunits that use this file. For reasons that I do not yet understand, these workunits seem to have been generated with incorrect md5sums for the file in question. I am investigating.

    Bruce Allen
    Bruce Allen
    Joined: 15 Oct 04
    Posts: 958
    Credit: 170,849,008
    RAC: 0

    md5 check failed

    21 Aug 2008 20:37:30 UTC
    Message 3576
    (moderation:
      )

      Kudoes for spotting this problem!

      We found a corrupted file on the E@H server. The wrong md5 sum was being shipped out. I have just fixed this in the workunits (replace incorrect md5 sum with the correct one):

      mysql> update workunit set xml_doc=REPLACE(xml_doc,"c2c67b1cf86121f7b79d8184069e9926","0b35efca8e47808f6b751a8045e7113c") where xml_doc like '%l1_0873.00_S5R4%' limit 200;
Query OK, 115 rows affected (14.41 sec)
Rows matched: 126  Changed: 115  Warnings: 0
      


      mysql> select count(id) from workunit where xml_doc like '%l1_0873.00_S5R4%' and xml_doc like '%c2c67b1cf86121f7b79d8184069e9926%' ;
      
+-----------+
      
| count(id) |
      
+-----------+
      
|         0 |
      
+-----------+
      
1 row in set (10.90 sec)
      


      mysql> select count(id) from workunit where xml_doc like '%l1_0873.00_S5R4%' and xml_doc like '%0b35efca8e47808f6b751a8045e7113c%' ;
      
+-----------+
      
| count(id) |
      
+-----------+
      
|       126 |
      
+-----------+
      
1 row in set (10.67 sec)

      This means that approximate 250 'results in progress' are going to fail because they have the wrong md5 sum. We'll then generate new results for these workunits that should succeed. I'm keeping my fingers crossed that this is a 'one time' corruption problem on the download server and not something that will occurr a lot!

      Cheers,
      Bruce

      Bruce Allen
      Bruce Allen
      Joined: 15 Oct 04
      Posts: 958
      Credit: 170,849,008
      RAC: 0

      RE: 18.08.2008

      21 Aug 2008 21:11:35 UTC
      Message 3577
      (moderation:
        )

        Quote:

        18.08.2008 12:43:26|Einstein@Home|[error] MD5 check failed for l1_0873.00_S5R4
        ...
        20.08.2008 18:54:55|Einstein@Home|[error] MD5 check failed for l1_0873.00_S5R4
        20.08.2008 18:54:55|Einstein@Home|[error] expected c2c67b1cf86121f7b79d8184069e9926, got 0b35efca8e47808f6b751a8045e7113c
        20.08.2008 18:54:55|Einstein@Home|[error] Checksum or signature error for l1_0873.00_S5R4

        Reproduced at least 10 times for this file.

        Rostislav,

        Thank you very much for spotting and reporting this problem. We are currently running scripts to check that there are no other data files on our download server with corrupted md5 sums.

        I've reset nresults_today to ZERO for the machine which was seeing these errors. This should prevent it from being penalized for the failures, so it should get more work (hopefully with the correct md5 sums now). You might want to detach and reattach the machine if it keeps getting errors from this file.

        Thanks also for your support of Einstein@Home. I see that you joined the project just a couple of days after our public launch on February 19, 2005.

        Cheers,
        Bruce

        Comment viewing options

        Select your preferred way to display the comments and click "Save settings" to activate your changes.

        Forums › Problems and Bug Reports