App info question

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1364
Credit: 3562358667
RAC: 1580

RE: Upps.... I don't think

Message 96629 in response to message 96624

Quote:
Upps.... I don't think this is healthy, currently there is no 3.05 S5R6 app for Windows (the app version didn't change so it's x.01 on all platforms), but there could be in the future, so you don't want to have a 305 S5R6 version in your app_info.xml.

Is having one in client_state.xml a problem? If yes I won't be the only person in trouble (the app_info file I'm using was made by someone else here) and on machines that are app_info free the app_version element is lingering in client_state.xml

this is from client_state.xml on a machine that used to (but no longer does) have an a copy of offending app_info.xml files.

[pre]

einstein_S5R6
305
windows_intelx86
1.000000
1.000000
1360623717.060821
6.3.0

einstein_S5R5_3.05_windows_intelx86.exe



einstein_S5R5_3.05_windows_intelx86_0.exe


einstein_S5R5_3.05_windows_intelx86_1.exe


einstein_S5R5_3.05_windows_intelx86_2.exe


einstein_S5R5_3.05_graphics_windows_intelx86.exe
graphics_app

[/pre]

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1364
Credit: 3562358667
RAC: 1580

...and success in eradicating

...and success in eradicating the app_info file without needing to do a reset.

The missing element was needing to cope the blocks to the client_state.xml as well. Apparently only app_info executables can get away without being signed.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109377202883
RAC: 35979782

RE: Edit: I see that Gary

Message 96631 in response to message 96626

Quote:
Edit: I see that Gary made a more useful version of this comment while I was away typing.


:-).

Often I'm the one that gets 'beaten' but you get lucky sometimes :-).

Actually, I left out one other course of action which would be the one I'd do if Dan was employing me as a consultant :-).

Unless you really know what you are doing, this is probably a bit scary - but it's actually safer than trying to futz with task branding and then getting app_info.xml right. Here are the steps

  • * Set NNT and wait for all ABP2 tasks to finish (I'm presuming that there are very few, if any, of those).
    * When you only have GW left, suspend all unstarted ones and wait for the 'in-flight' GW's to finish - it doesn't matter about any other project tasks. However you may wish to stop other projects trying to 'fill the gap' just before you suspend the GW tasks.
    * When all 'in-flight' GW's are finished and reported, completely stop BOINC.
    * Delete app_info.xml but nothing else.
    * Make a backup copy of your BOINC Data folder (just in case ...)
    * Open the main state file (client_state.xml) with a text editor like notepad (not a browser) and scroll down until you find the start of the E@H project.
    * After the closing tag, look for any ... clauses and delete any that refer to S5R* making sure to remove only the tags and what is between them.
    * Then look for ... tags which refer to S5R5 executables and delete them as before. make sure you leave any of these tags that refer to data files, sun, earth, h1_*, l1_*, etc well alone.
    * Keep scanning down the file past large numbers of tags that contain the internal tags , , and . These are some sort of output templates that get filled in when tasks are crunched and then will contain a value other than zero. There will be as many of these 's as there are suspended tasks. These tags should be left alone.

Following these there will be ... tags which have actually been inserted from your app_info.xml. You need to delete these so that BOINC has a 'clean slate' when it restarts. This avoids any need for a project reset.

Following these you will find ... tags which you will also not touch. These clauses are quite large and have an easily recognisable internal structure where all the large data files involved are listed. They also contain the parameters used by the app to crunch a task. Once again there will be as many of these as there are suspended tasks.

Then you will come to the bit you are really looking for - the ... tags which will contain the version number branding amongst other things. These are the result templates sent to you and which E@H will always resend if they become 'lost'. So the key trick is to 'lose' them all and have the server resend them all. This way all the task branding will be fixed up in one fell swoop. If you have 100 suspended tasks, you will find 100 tags, each containing a which is the name you see on the tasks list in BOINC Manager. These are all to be deleted, being careful not to delete anything past the very last tag. This will be quite close to the end of the E@H section of client_state.xml.
* Having removed all your wrongly branded results you can save your state file. Before restarting BOINC, disconnect your network cable temporarily so that if all goes pearshaped you can stop BOINC and revert to your saved copy. If BOINC restarts without major complaint (eg systax errors) you can plug your cable back in and check that your S5R6 and ABP2 apps are still in your project folder. If they are not, insert new copies to save unnecessary downloading.
* Now you can ANT (reverse of NNT) and 'update'. You should expect to see a flood of red (quite alarming the first time I saw it :-) ) but it will simply be all your lost tasks being restored to you. Gotta love that feature :-).

I've tried to be as complete as possible with the above instructions. I've used this 'resend lost results' trick about 20 times in the last couple of years so I know it works. In my case it was mainly to get rid of corrupted tasks where the network was fortunately disabled (I turn off the comms during my ISP's 'peak' charge period) and the whole cache had errored out due to spurious errors related to corruption during unzipping, etc, rather than an actual crunch error. It's a long story but the recovery was always successful when there hadn't been any communication with the servers.

If you want to try this and you need more instructions, please ask.

Cheers,
Gary.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109377202883
RAC: 35979782

RE: ...and success in

Message 96632 in response to message 96630

Quote:

...and success in eradicating the app_info file without needing to do a reset.

The missing element was needing to cope the blocks to the client_state.xml as well. Apparently only app_info executables can get away without being signed.


I see you have moved on quite a ways while I was composing my marathon piece :-).

You may have already 'fixed' your problem if I interpret you correctly by getting an app_info.xml that works correctly. Are you saying that you are now crunching GW tasks under AP but using the correct S5R6 application?

When bailing out of AP, there are three key strategies -

1. Set NNT, empty cache and report, delete app_info, reset the project, get everything (data & apps) fresh.

2. Set NNT, empty cache and report, delete app_info ONLY, remove AP stuff from client_state, DON'T reset, get new apps & tasks but keep existing large data files.

3. Stop BOINC anytime, delete app_info ONLY, edit client_state to remove inserted AP stuff, add to client_state 'official' files and signatures from another machine, restart BOINC and continue on from where you left off.

This third option applies where the AP app and the 'official' app are the same name and version (eg a beta test app has just been made official). You obviously know what you are doing so the above should be clear to you. I've actually done option 3. in the past but it was a while ago (Bernd doesn't seem to run beta test apps any more) and my memory may have forgotten something else that was obvious at the time ;-).

Cheers,
Gary.

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1364
Credit: 3562358667
RAC: 1580

RE: RE: ...and success in

Message 96633 in response to message 96632

Quote:
Quote:

...and success in eradicating the app_info file without needing to do a reset.

The missing element was needing to cope the blocks to the client_state.xml as well. Apparently only app_info executables can get away without being signed.


I see you have moved on quite a ways while I was composing my marathon piece :-).

You may have already 'fixed' your problem if I interpret you correctly by getting an app_info.xml that works correctly. Are you saying that you are now crunching GW tasks under AP but using the correct S5R6 application?

I was well ahead of you. I had them running on the s5r6 executable as of post 102064. This one was where I found the last thing I needed to edit to remove the app_info without any problems.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109377202883
RAC: 35979782

RE: I was well ahead of

Message 96634 in response to message 96633

Quote:
I was well ahead of you. I had them running on the s5r6 executable as of post 102064. This one was where I found the last thing I needed to edit to remove the app_info without any problems.


Aaahhh... that 'last thing' being the copying of the blocks containing the 'official' signatures, I presume?

I didn't, at first glance, realise that

Quote:
The missing element was needing to cope the blocks to the client_state.xml as well.


actually meant 'inserting the missing signatures' :-). I actually used to put signatures into app_info.xml but these days I think BOINC sees it as 'illegal' {for obvious reasons) to do that :-).

Cheers,
Gary.

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1364
Credit: 3562358667
RAC: 1580

RE: RE: I was well ahead

Message 96635 in response to message 96634

Quote:
Quote:
I was well ahead of you. I had them running on the s5r6 executable as of post 102064. This one was where I found the last thing I needed to edit to remove the app_info without any problems.

Aaahhh... that 'last thing' being the copying of the blocks containing the 'official' signatures, I presume?

I didn't, at first glance, realise that

Quote:
The missing element was needing to cope the blocks to the client_state.xml as well.

actually meant 'inserting the missing signatures' :-). I actually used to put signatures into app_info.xml but these days I think BOINC sees it as 'illegal' {for obvious reasons) to do that :-).

yup

Comment viewing options

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