acct_mgr_request.xml - Not valid XML #1470

Closed
Kati3e opened this Issue Jan 17, 2016 · 26 comments

Comments

Projects
None yet
@Kati3e

Kati3e commented Jan 17, 2016

Run into another issue today with a user not being able to connect correctly to my account manager. After some debugging I have found the exact cause. The acct_mgr_request.xml is not valid XML due to a closing tag not being there. This issue was present on 2 machines, both running a different distro of Linux and versions of BOINC. (Ubuntu with 7.2.42 and ArchLinux with 7.6.22).

I've included a portion of the XML where the tag is missing.

I'm assuming this is an issue with World Community Grid, but I don't know exactly how this all works or who I should report this to, to get it fixed.

And shouldn't BOINC be validating XML before sending and receiving it? This seems like best practice to me.. Invalid XML could wreck havoc if devs aren't checking it before parsing.

Notice the missing </venue> tag for <venue name="work">
This will fail any XML validation methods..

<global_preferences>

<source_project>http://www.worldcommunitygrid.org/</source_project>
    <source_scheduler>https://scheduler.worldcommunitygrid.org/boinc/wcg_cgi/fcgi</source_scheduler>

    <mod_time>1450950386</mod_time>
    <run_on_batteries>0</run_on_batteries>
    <run_if_user_active>1</run_if_user_active>
    <run_gpu_if_user_active>0</run_gpu_if_user_active>
    <idle_time_to_run>3</idle_time_to_run>
    <suspend_if_no_recent_input>0.0</suspend_if_no_recent_input>
    <suspend_cpu_usage>60.0</suspend_cpu_usage>
    <leave_apps_in_memory>0</leave_apps_in_memory>
    <cpu_scheduling_period_minutes>60</cpu_scheduling_period_minutes>
    <max_ncpus_pct>100.0</max_ncpus_pct>
    <cpu_usage_limit>100.0</cpu_usage_limit>
    <disk_max_used_gb>50.0</disk_max_used_gb>
    <disk_min_free_gb>1.0</disk_min_free_gb>
    <disk_max_used_pct>90.0</disk_max_used_pct>
    <disk_interval>60.0</disk_interval>
    <vm_max_used_pct>75.0</vm_max_used_pct>
    <ram_max_used_busy_pct>50.0</ram_max_used_busy_pct>
    <ram_max_used_idle_pct>90.0</ram_max_used_idle_pct>
    <work_buf_min_days>0.1</work_buf_min_days>
    <work_buf_additional_days>0.5</work_buf_additional_days>
    <confirm_before_connecting>0</confirm_before_connecting>
    <hangup_if_dialed>0</hangup_if_dialed>
    <max_bytes_sec_down>200000.0</max_bytes_sec_down>
    <max_bytes_sec_up>100000.0</max_bytes_sec_up>
    <daily_xfer_limit_mb>0.0</daily_xfer_limit_mb>
    <daily_xfer_period_days>0</daily_xfer_period_days>
    <dont_verify_images>0</dont_verify_images>
    <end_hour>0</end_hour>
    <net_end_hour>0</net_end_hour>
    <net_start_hour>0</net_start_hour>
    <start_hour>0</start_hour>
    <venue name="home">
        <confirm_before_connecting/>
        <cpu_scheduling_period_minutes>60</cpu_scheduling_period_minutes>
        <disk_interval>60.0</disk_interval>
        <disk_max_used_gb>50.0</disk_max_used_gb>
        <disk_max_used_pct>90.0</disk_max_used_pct>
        <disk_min_free_gb>0.0</disk_min_free_gb>
        <end_hour>0</end_hour>
        <hangup_if_dialed/>
        <leave_apps_in_memory/>
        <max_bytes_sec_down>200000.0</max_bytes_sec_down>
        <max_bytes_sec_up>100000.0</max_bytes_sec_up>
        <daily_xfer_period_days>0</daily_xfer_period_days>
        <daily_xfer_limit_mb>0.0</daily_xfer_limit_mb>
        <max_ncpus_pct>100.0</max_ncpus_pct>
        <suspend_cpu_usage>60.0</suspend_cpu_usage>
        <net_end_hour>0</net_end_hour>
        <net_start_hour>0</net_start_hour>
        <run_if_user_active/>
        <run_gpu_if_user_active/>
        <run_on_batteries/>
        <start_hour>0</start_hour>
        <cpu_usage_limit>100.0</cpu_usage_limit>
        <ram_max_used_busy_pct>50.0</ram_max_used_busy_pct>
        <ram_max_used_idle_pct>90.0</ram_max_used_idle_pct>
        <vm_max_used_pct>75.0</vm_max_used_pct>
        <work_buf_min_days>0.1</work_buf_min_days>
        <work_buf_additional_days>0.1</work_buf_additional_days>
        <suspend_if_no_recent_input>0.0</suspend_if_no_recent_input>
    </venue>
    <venue name="work">
        <confirm_before_connecting/>
        <cpu_scheduling_period_minutes>60</cpu_scheduling_period_minutes>
        <disk_interval>60.0</disk_interval>
        <disk_max_used_gb>50.0</disk_max_used_gb>
        <disk_max_used_pct>80.0</disk_max_used_pct>
        <disk_min_free_gb>1.0</disk_min_free_gb>
        <end_hour>0</end_hour>
        <hangup_if_dialed/>
        <leave_apps_in_memory/>
        <max_bytes_sec_down>200000.0</max_bytes_sec_down>
        <max_bytes_sec_up>100000.0</max_bytes_sec_up>
        <daily_xfer_period_days>0</daily_xfer_period_days>
        <daily_xfer_limit_mb>0.0</daily_xfer_limit_mb>
        <max_ncpus_pct>100.0</max_ncpus_pct>
        <suspend_cpu_usage>60.0</suspend_cpu_usage>
        <net_end_hour>0</net_end_hour>
        <net_start_hour>0</net_start_hour>
        <run_if_user_active/>
        <run_gpu_if_user_active/>
        <run_on_batteries/>
        <start_hour>0</start_hour>
        <cpu_usage_limit>100.0</cpu_usage_limit>
        <ram_max_used_busy_pct>50.0</ram_max_used_busy_pct>
        <ram_max_used_idle_pct>90.0</ram_max_used_idle_pct>
        <vm_max_used_pct>75.0</vm_max_used_pct>
        <work_buf_min_days>0.1</work_buf_min_days>
        <work_buf_additional_days>0.5</work_buf_additional_days>
        <suspend_if_no_recent_input>0.0</suspend_if_no_recent_input>
</global_preferences>
@m4gu5

This comment has been minimized.

Show comment
Hide comment
@m4gu5

m4gu5 Jan 17, 2016

I am the user that reported the issue to Kati3e.
This most likely is an issue on WCGs side. I changed my global prefs from within another project (Universe@home) and updated the project in the BOINC Manager to get the global prefs fetched from there. After this, attaching to the account manager worked. The file acct_mgr_request.xml was valid and contained the closing tag </venue>.
Did this successfully on both hosts (Ubuntu & ArchLinux).

Additional information on the issue
When the global prefs were last updated from WCG, thus fetched from there, the error message upon issuing boinccmd --join_acct_mgr is

poll status: operation in progress
poll status: operation in progress
poll status: operation in progress
poll status: unexpected XML tag or syntax

I did some googling on this and found a few message board threads were users were reporting that problem. I think all those errors could have been related to this issue but nobody ever traced it back to WCG sending an invalid XML file:
https://boincstats.com/en/forum/9/9943,1
https://www.dslreports.com/forum/r29970351-Help-BOINC-move
https://boinc.berkeley.edu/dev/forum_thread.php?id=4531

m4gu5 commented Jan 17, 2016

I am the user that reported the issue to Kati3e.
This most likely is an issue on WCGs side. I changed my global prefs from within another project (Universe@home) and updated the project in the BOINC Manager to get the global prefs fetched from there. After this, attaching to the account manager worked. The file acct_mgr_request.xml was valid and contained the closing tag </venue>.
Did this successfully on both hosts (Ubuntu & ArchLinux).

Additional information on the issue
When the global prefs were last updated from WCG, thus fetched from there, the error message upon issuing boinccmd --join_acct_mgr is

poll status: operation in progress
poll status: operation in progress
poll status: operation in progress
poll status: unexpected XML tag or syntax

I did some googling on this and found a few message board threads were users were reporting that problem. I think all those errors could have been related to this issue but nobody ever traced it back to WCG sending an invalid XML file:
https://boincstats.com/en/forum/9/9943,1
https://www.dslreports.com/forum/r29970351-Help-BOINC-move
https://boinc.berkeley.edu/dev/forum_thread.php?id=4531

@Kati3e

This comment has been minimized.

Show comment
Hide comment
@Kati3e

Kati3e Jan 17, 2016

poll status: unexpected XML tag or syntax

Actually happens quite often and is a result of the acct_mgr_reply.xml

Even when the issue isn't related to XML tags or syntax.. Seems to me its just a general error that doesn't actually report on what the real underlying problem is.

In this case it's not related to the global preference issue. It happens because my account manager sent back <error> tags, which seem to cause the polling status to report that.

Kati3e commented Jan 17, 2016

poll status: unexpected XML tag or syntax

Actually happens quite often and is a result of the acct_mgr_reply.xml

Even when the issue isn't related to XML tags or syntax.. Seems to me its just a general error that doesn't actually report on what the real underlying problem is.

In this case it's not related to the global preference issue. It happens because my account manager sent back <error> tags, which seem to cause the polling status to report that.

@ChristianBeer

This comment has been minimized.

Show comment
Hide comment
@ChristianBeer

ChristianBeer Jan 21, 2016

Member

We have seen the missing </venue> tag on EaH too. We are not sure where this comes from. We have seen it propagate from WCG and BAM. I think the issue is fixed but every user affected has to change preferences slightly so the tag is inserted and propagated to other projects.

Member

ChristianBeer commented Jan 21, 2016

We have seen the missing </venue> tag on EaH too. We are not sure where this comes from. We have seen it propagate from WCG and BAM. I think the issue is fixed but every user affected has to change preferences slightly so the tag is inserted and propagated to other projects.

@davidpanderson

This comment has been minimized.

Show comment
Hide comment
@davidpanderson

davidpanderson Jan 22, 2016

Contributor

The way the client parses global prefs doesn't flag missing as an error.
It then passes the text in scheduler and AM requests.
This is bad.
I'll add code to reject prefs with missing .
-- David

On 1/20/2016 11:33 PM, Christian Beer wrote:

We have seen the missing || tag on EaH too. We are not sure where this
comes from. We have seen it propagate from WCG and BAM. I think the issue is fixed
but every user affected has to change preferences slightly so the tag is inserted
and propagated to other projects.


Reply to this email directly or view it on GitHub
#1470 (comment).

Contributor

davidpanderson commented Jan 22, 2016

The way the client parses global prefs doesn't flag missing as an error.
It then passes the text in scheduler and AM requests.
This is bad.
I'll add code to reject prefs with missing .
-- David

On 1/20/2016 11:33 PM, Christian Beer wrote:

We have seen the missing || tag on EaH too. We are not sure where this
comes from. We have seen it propagate from WCG and BAM. I think the issue is fixed
but every user affected has to change preferences slightly so the tag is inserted
and propagated to other projects.


Reply to this email directly or view it on GitHub
#1470 (comment).

@davidpanderson

This comment has been minimized.

Show comment
Hide comment
@davidpanderson

davidpanderson Jan 22, 2016

Contributor

Actually I'm not seeing a clean way to do this, short of adding a "real" XML parser to the client.

Contributor

davidpanderson commented Jan 22, 2016

Actually I'm not seeing a clean way to do this, short of adding a "real" XML parser to the client.

@brevilo

This comment has been minimized.

Show comment
Hide comment
@brevilo

brevilo Jan 22, 2016

Contributor

Then why not just fix this once and for all? We've already had so many issues and discussions about BOINC's incomplete/buggy XML parser over the years, including the one stated here.

For that reason we (E@H) are going to reject invalid XML we receive via web RPCs as soon as we switch to Drupal for our main project. We don't want our project database be messed up with broken XML anymore. I'm glad that BAM! as central entity now seemingly enabled XML validation as well 👍

Speaking of "shortness": maintaining this custom implementation has already and will continue to cost you way more effort than switching to, say, libxml2 and be done with it - let alone all downstream projects that need to fix unnecessarily broken XML. But I repeat myself again...

Contributor

brevilo commented Jan 22, 2016

Then why not just fix this once and for all? We've already had so many issues and discussions about BOINC's incomplete/buggy XML parser over the years, including the one stated here.

For that reason we (E@H) are going to reject invalid XML we receive via web RPCs as soon as we switch to Drupal for our main project. We don't want our project database be messed up with broken XML anymore. I'm glad that BAM! as central entity now seemingly enabled XML validation as well 👍

Speaking of "shortness": maintaining this custom implementation has already and will continue to cost you way more effort than switching to, say, libxml2 and be done with it - let alone all downstream projects that need to fix unnecessarily broken XML. But I repeat myself again...

@chausner

This comment has been minimized.

Show comment
Hide comment
@chausner

chausner Mar 24, 2016

Contributor

+1 for generating valid XML for the RPCs. I am currently working on an alternative GUI application and am running into cases where BOINC responds with incorrect XML (e.g. message bodies are not escaped correctly). It is very ugly and fragile having to work around this.

Contributor

chausner commented Mar 24, 2016

+1 for generating valid XML for the RPCs. I am currently working on an alternative GUI application and am running into cases where BOINC responds with incorrect XML (e.g. message bodies are not escaped correctly). It is very ugly and fragile having to work around this.

@grctest

This comment has been minimized.

Show comment
Hide comment
@grctest

grctest Apr 26, 2016

The following BOINC projects do not have closing XML tags thusly the XML does not render correctly (semi on-topic regarding XML formatting):

Edit: Nevermind, I was mistaken.

http://www.distributeddatamining.org/DistributedDataMining/server_status.php?xml=1
https://einstein.phys.uwm.edu/server_status.php?xml=1
http://www.rechenkraft.net/yoyo/server_status.php?xml=1

grctest commented Apr 26, 2016

The following BOINC projects do not have closing XML tags thusly the XML does not render correctly (semi on-topic regarding XML formatting):

Edit: Nevermind, I was mistaken.

http://www.distributeddatamining.org/DistributedDataMining/server_status.php?xml=1
https://einstein.phys.uwm.edu/server_status.php?xml=1
http://www.rechenkraft.net/yoyo/server_status.php?xml=1

@brevilo

This comment has been minimized.

Show comment
Hide comment
@brevilo

brevilo Apr 27, 2016

Contributor

@grctest where does the einstein server status lack closing tags? I can't find any and xmllint also doesn't complain about the well-formedness. Where does it not "render" correctly?

Contributor

brevilo commented Apr 27, 2016

@grctest where does the einstein server status lack closing tags? I can't find any and xmllint also doesn't complain about the well-formedness. Where does it not "render" correctly?

@grctest

This comment has been minimized.

Show comment
Hide comment
@grctest

grctest Apr 27, 2016

@brevilo You're right, I was mistaken - there isn't visibly any reason in the source why the xml is showing different in the browser: https://i.imgur.com/43bdLZC.jpg (comparing milkyway to ddm). False negative on my part, nevermind.

grctest commented Apr 27, 2016

@brevilo You're right, I was mistaken - there isn't visibly any reason in the source why the xml is showing different in the browser: https://i.imgur.com/43bdLZC.jpg (comparing milkyway to ddm). False negative on my part, nevermind.

@brevilo

This comment has been minimized.

Show comment
Hide comment
@brevilo

brevilo Apr 27, 2016

Contributor

Well that's most likely because of the php extension that let's the browser interpret the file as web content (mime type text/html), not as pure XML. Thus it complains about the missing DOCTYPE declaration for instance.

Contributor

brevilo commented Apr 27, 2016

Well that's most likely because of the php extension that let's the browser interpret the file as web content (mime type text/html), not as pure XML. Thus it complains about the missing DOCTYPE declaration for instance.

@grcjamezz

This comment has been minimized.

Show comment
Hide comment
@grcjamezz

grcjamezz Aug 6, 2016

Kati3e , hello and thank you for the service and help you provide.
I had this issue happen last week via 2 linux boxes and it seemed to resolve itself as my 7 windows 3 android devices had no issues. But 3 days ago this issue came back , I cannot edit settings as they are under gridcoin/team gridcoin from the pool so per the faq I cannot fix this issue myself. I have removed and tried editing the xml files , detached and attached from the manager. Please advise me on the issue or how to resolve. Thank you for your time in advance and again for your service.

Kati3e , hello and thank you for the service and help you provide.
I had this issue happen last week via 2 linux boxes and it seemed to resolve itself as my 7 windows 3 android devices had no issues. But 3 days ago this issue came back , I cannot edit settings as they are under gridcoin/team gridcoin from the pool so per the faq I cannot fix this issue myself. I have removed and tried editing the xml files , detached and attached from the manager. Please advise me on the issue or how to resolve. Thank you for your time in advance and again for your service.

@grcjamezz

This comment has been minimized.

Show comment
Hide comment
@grcjamezz

grcjamezz Aug 6, 2016

correction and update:
After playing around a while I found a fix and have helped a few on freenode #gridcoin.
Since as a user , we have no way to globally edit preferences per user gridcoin on any projects this is what I did.
First , add a project and manually select one outside of the pool , I used seti@home beta https://setiweb.ssl.berkeley.edu/beta/
Second , I clicked update per that 1 project.
Third , I clicked synchronize with pool.gridcoin.co and walla update complete!

I was then able to remove the project and sync again without issues. This has worked for many others and I hope it helps anyone in the mean time till there is a terminate fix. Thank you again Katie and GRC Team and the rest of the community.

correction and update:
After playing around a while I found a fix and have helped a few on freenode #gridcoin.
Since as a user , we have no way to globally edit preferences per user gridcoin on any projects this is what I did.
First , add a project and manually select one outside of the pool , I used seti@home beta https://setiweb.ssl.berkeley.edu/beta/
Second , I clicked update per that 1 project.
Third , I clicked synchronize with pool.gridcoin.co and walla update complete!

I was then able to remove the project and sync again without issues. This has worked for many others and I hope it helps anyone in the mean time till there is a terminate fix. Thank you again Katie and GRC Team and the rest of the community.

@grcjamezz

This comment has been minimized.

Show comment
Hide comment
@grcjamezz

grcjamezz Aug 6, 2016

Linux: Per my boinc clients on Debian based machines ( ubuntu / kali / bodhi etc ) installed via a debian package such as using " apt-get install boinc " my machines are headless and run boinctui , my Centos machine uses windows for a manager. If you have rpc setup and use the windows boinc client manager the process was the same as windows.
Per using ssh/cli and boinctui , I exited boinctui and per my setup went to my boinc data dir /var/lib/boinc-client where you will find your projects .xml files along with the account managers .xml files etc. Then grabbed my key file info from seti@home beta and created the file account_setiweb.ssl.berkeley.edu_beta.xml with the proper login/pass key info. Then " sudo service boinc-client restart " so it loaded boinc and included the project seti@home beta as a new solo project with new global settings.
Then I started boinctui again and selected Projects/Sync with pool.gridcoin.co and walla!

Now I did run into trouble on a 2nd box oddly same machine 100% hardware/os and I had to detach from the account manager , and detach from every project and then goto that same directory and rm -Rf acct_mgr_* and boinccmd --join_acct_mgr pool.gridcoin.co email@domain.com password and rejoin , thus since the ID was not removed it instantly synced with pool.gridcoin.co and pulled down a new working .xml file.

I hope this helps anyone with Linux whom may still be having problems.

Linux: Per my boinc clients on Debian based machines ( ubuntu / kali / bodhi etc ) installed via a debian package such as using " apt-get install boinc " my machines are headless and run boinctui , my Centos machine uses windows for a manager. If you have rpc setup and use the windows boinc client manager the process was the same as windows.
Per using ssh/cli and boinctui , I exited boinctui and per my setup went to my boinc data dir /var/lib/boinc-client where you will find your projects .xml files along with the account managers .xml files etc. Then grabbed my key file info from seti@home beta and created the file account_setiweb.ssl.berkeley.edu_beta.xml with the proper login/pass key info. Then " sudo service boinc-client restart " so it loaded boinc and included the project seti@home beta as a new solo project with new global settings.
Then I started boinctui again and selected Projects/Sync with pool.gridcoin.co and walla!

Now I did run into trouble on a 2nd box oddly same machine 100% hardware/os and I had to detach from the account manager , and detach from every project and then goto that same directory and rm -Rf acct_mgr_* and boinccmd --join_acct_mgr pool.gridcoin.co email@domain.com password and rejoin , thus since the ID was not removed it instantly synced with pool.gridcoin.co and pulled down a new working .xml file.

I hope this helps anyone with Linux whom may still be having problems.

@denravonska

This comment has been minimized.

Show comment
Hide comment
@denravonska

denravonska Aug 7, 2016

Contributor

@grcjamezz suggestion worked for me.

  1. Add SETI
  2. Go to SETI page and make a change in the preferences
  3. Update SETI in BOINC Manager
  4. Refresh pool
Contributor

denravonska commented Aug 7, 2016

@grcjamezz suggestion worked for me.

  1. Add SETI
  2. Go to SETI page and make a change in the preferences
  3. Update SETI in BOINC Manager
  4. Refresh pool
@Doempie

This comment has been minimized.

Show comment
Hide comment
@Doempie

Doempie Aug 8, 2016

I am very new to BOINC and Gridcoin and I have had the same issue and the following solution worked for me (eventhough you have to completely reinstall BOINC on your system. (Windows 10)

  1. Uninstall BOINC
  2. Delete the BOINC folder in c:\ProgramData (If you do not see the folder, go to File Explorer, on the tab on top click on VIEW then select OPTIONS [way on the right] then click on "Change Folder And Search Options" and make sure Show Hidden Files is ticked and that Hide protected system files are unticked"
  3. Go to C:\Program Files\Boinc and check that no remnants of Boinc are left there.
  4. Reinstall Boinc and reload your projects.
  5. Should work :)

It seems that a file gets corrupted under the ProgramData whilst loading/syncing projects.

Donations are welcome: S7w75bmQNGVVuAtRBTD4gRDVJDXcRr4hGz

Doempie commented Aug 8, 2016

I am very new to BOINC and Gridcoin and I have had the same issue and the following solution worked for me (eventhough you have to completely reinstall BOINC on your system. (Windows 10)

  1. Uninstall BOINC
  2. Delete the BOINC folder in c:\ProgramData (If you do not see the folder, go to File Explorer, on the tab on top click on VIEW then select OPTIONS [way on the right] then click on "Change Folder And Search Options" and make sure Show Hidden Files is ticked and that Hide protected system files are unticked"
  3. Go to C:\Program Files\Boinc and check that no remnants of Boinc are left there.
  4. Reinstall Boinc and reload your projects.
  5. Should work :)

It seems that a file gets corrupted under the ProgramData whilst loading/syncing projects.

Donations are welcome: S7w75bmQNGVVuAtRBTD4gRDVJDXcRr4hGz

@WhiteCat6142

This comment has been minimized.

Show comment
Hide comment
@WhiteCat6142

WhiteCat6142 Aug 9, 2016

I reset all my settings under Boinc folder,but it was broken again just in some hours.
And I add close tag manually,but it does not work.
What I do is changing settings and syncing with "http://pool.gridcoin.co" .That's all.
I have no idea how to fix this.

I got it. http://pool.gridcoin.co/faq/

WhiteCat6142 commented Aug 9, 2016

I reset all my settings under Boinc folder,but it was broken again just in some hours.
And I add close tag manually,but it does not work.
What I do is changing settings and syncing with "http://pool.gridcoin.co" .That's all.
I have no idea how to fix this.

I got it. http://pool.gridcoin.co/faq/

@ChristianBeer

This comment has been minimized.

Show comment
Hide comment
@ChristianBeer

ChristianBeer Aug 9, 2016

Member

This can not be fixed on the Client. You need to update preferences of the account you are using with a project that creates valid XML. So far it seems that Seti, Einstein@Home or Universe@Home are a good choice. You need to attach the faulty client to one of these projects using the same account as with the Account Manager. Change a preference setting sligthly and update the project on the Client. This will propagate the fixed preferences to all the other projects. This works until you change preferences on a Project that produces this invalid XML.

Member

ChristianBeer commented Aug 9, 2016

This can not be fixed on the Client. You need to update preferences of the account you are using with a project that creates valid XML. So far it seems that Seti, Einstein@Home or Universe@Home are a good choice. You need to attach the faulty client to one of these projects using the same account as with the Account Manager. Change a preference setting sligthly and update the project on the Client. This will propagate the fixed preferences to all the other projects. This works until you change preferences on a Project that produces this invalid XML.

@grcjamezz

This comment has been minimized.

Show comment
Hide comment
@grcjamezz

grcjamezz Aug 10, 2016

Since I was not worried about my 3 android devices I had not updated them until last night , same error of course... I use native boinc vs boinc from the google playstore as you can use what ever manager you want not just BAM! and gridrepublic so you can goto manage client , add client manager , put in the user/pw and add projects...

Anyways , it was exactly the same.
Added seti@home and went to projects , update , then sync with the manager... On win/linux and android linux the procedure is all the same , and worked on all machines...

Add a solo project , update , sync all found in native boinc's manage client options and fixed.

Donations appreciated : S5WfKNACpRejpXrsQ4c9gWXrcPd8KyLj7K
( only added because someone with a problem asked for donations , when his solution was just to remove everything and start over , this is not fixing the problem but replacing all the files not just adding a project that parses together projects info into the file acct_mgr_reply.xml and is a complete waste of time in my opinion and resources that could be used for crunching. By doing that you are not fixing , you are starting over and it will give a new 4 digit machine ID at the pool/manager along with a new entry for that machine and make a new xml file , you must re attach projects , and it's as if you added a new machine and just started mining on it )

Also support team gridcoin and join us on irc.freenode.org #gridcoin and win GRC for being an active participant in chat! Thanks - jamezz

grcjamezz commented Aug 10, 2016

Since I was not worried about my 3 android devices I had not updated them until last night , same error of course... I use native boinc vs boinc from the google playstore as you can use what ever manager you want not just BAM! and gridrepublic so you can goto manage client , add client manager , put in the user/pw and add projects...

Anyways , it was exactly the same.
Added seti@home and went to projects , update , then sync with the manager... On win/linux and android linux the procedure is all the same , and worked on all machines...

Add a solo project , update , sync all found in native boinc's manage client options and fixed.

Donations appreciated : S5WfKNACpRejpXrsQ4c9gWXrcPd8KyLj7K
( only added because someone with a problem asked for donations , when his solution was just to remove everything and start over , this is not fixing the problem but replacing all the files not just adding a project that parses together projects info into the file acct_mgr_reply.xml and is a complete waste of time in my opinion and resources that could be used for crunching. By doing that you are not fixing , you are starting over and it will give a new 4 digit machine ID at the pool/manager along with a new entry for that machine and make a new xml file , you must re attach projects , and it's as if you added a new machine and just started mining on it )

Also support team gridcoin and join us on irc.freenode.org #gridcoin and win GRC for being an active participant in chat! Thanks - jamezz

@Doempie

This comment has been minimized.

Show comment
Hide comment
@Doempie

Doempie Aug 10, 2016

Sorry that it wasted your time...but for me when I added Seti@home it still didnt, work. And I asked for donations not because of the solution but just because I was hoping someone would kindly give me donations since I am starting new on Gridcoins, sorry I wasted your time.

Doempie commented Aug 10, 2016

Sorry that it wasted your time...but for me when I added Seti@home it still didnt, work. And I asked for donations not because of the solution but just because I was hoping someone would kindly give me donations since I am starting new on Gridcoins, sorry I wasted your time.

@ChristianBeer

This comment has been minimized.

Show comment
Hide comment
@ChristianBeer

ChristianBeer Sep 6, 2016

Member

We just uncovered that this is a known issue from 4 years ago. At one time there was a new script introduced in d2d9110 which fixes this problem. It is now in html/ops/fix_prefs.php.
The real problem is that the root cause for this mangled XML was never found and we are now still haunted with it.

Member

ChristianBeer commented Sep 6, 2016

We just uncovered that this is a known issue from 4 years ago. At one time there was a new script introduced in d2d9110 which fixes this problem. It is now in html/ops/fix_prefs.php.
The real problem is that the root cause for this mangled XML was never found and we are now still haunted with it.

@brevilo

This comment has been minimized.

Show comment
Hide comment
@brevilo

brevilo Sep 6, 2016

Contributor

Also, we can exclude the am_set_info() RPC which we (E@H) protected by an input validation when we switched to our Drupal web frontend - yet we do see newly missing </venue> tags in our DB again (after having fixed them).

This leaves the scheduler which receives the prefs updates from the client, potentially getting them from yet unfixed upstream prefs from other projects. We're going to close that gap as well and will reject such crippled prefs XML updates in the near future.

Contributor

brevilo commented Sep 6, 2016

Also, we can exclude the am_set_info() RPC which we (E@H) protected by an input validation when we switched to our Drupal web frontend - yet we do see newly missing </venue> tags in our DB again (after having fixed them).

This leaves the scheduler which receives the prefs updates from the client, potentially getting them from yet unfixed upstream prefs from other projects. We're going to close that gap as well and will reject such crippled prefs XML updates in the near future.

@RichardHaselgrove

This comment has been minimized.

Show comment
Hide comment
@RichardHaselgrove

RichardHaselgrove Oct 26, 2016

Contributor

The effect of 773e8a8 (the change requested in #1676) has been tested on the SETI@Home Beta server, and appears to solve the issue at source - although I don't think it will automatically fix previously-broken preference sets.

Contributor

RichardHaselgrove commented Oct 26, 2016

The effect of 773e8a8 (the change requested in #1676) has been tested on the SETI@Home Beta server, and appears to solve the issue at source - although I don't think it will automatically fix previously-broken preference sets.

@ChristianBeer

This comment has been minimized.

Show comment
Hide comment
@ChristianBeer

ChristianBeer Oct 26, 2016

Member

I'm going to send an email to boinc_projects tomorrow and point other projects to html/ops/fix_prefs.php which repairs the broken preference sets.
It took almost a year from first report to a working fix. And the fix in the end is a one-line change. Oh my.

Member

ChristianBeer commented Oct 26, 2016

I'm going to send an email to boinc_projects tomorrow and point other projects to html/ops/fix_prefs.php which repairs the broken preference sets.
It took almost a year from first report to a working fix. And the fix in the end is a one-line change. Oh my.

@RichardHaselgrove

This comment has been minimized.

Show comment
Hide comment
@RichardHaselgrove

RichardHaselgrove Oct 26, 2016

Contributor

And it took not much over a day from deciding to engage with the issue, to following the chain of events back to where that one-line change was needed.

Contributor

RichardHaselgrove commented Oct 26, 2016

And it took not much over a day from deciding to engage with the issue, to following the chain of events back to where that one-line change was needed.

@grctest

This comment has been minimized.

Show comment
Hide comment
@grctest

grctest Oct 26, 2016

Thanks guys, much appreciated! :D

grctest commented Oct 26, 2016

Thanks guys, much appreciated! :D

@BOINC BOINC locked and limited conversation to collaborators Nov 20, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.