As long as the scientific application still resides in the project directory, the app_config can't complain about the missing application. But you have to have run some of the work that the application is meant for and received the app at least once.
But if you cause the application to be deleted from the client_state files by injudicous meddling around in files, the application can be deleted from your project folder and then the error message from the app_info file can kick back in because the app is no longer resident.
If you are trying to get work for a new app you copy the science app to directory outside of BOINC so it can't delete the copy of the app so that you can retry editing of files. Or you can mark the application immutable so that neither BOINC or the system is able to delete it.
I had to do that for the BRP7 application that I was adding to my app_info to run alongside the Petri FGRPB1G application. I dumped work a couple of times and endured some 24 hour timeouts until I got the edits correct in the app_info and client_state files.
... If it's not running on your box, it can't be found. Makes sense. I'm not sure what you have to do to encourage the hsgamma_FGRPB1G 1.18 work units.
Unfortunately, the 'not running' bit has nothing to do with the 'problem' of not getting work. In fact there is no such 'problem' that requires you to do anything. To get FRGPB1G work, all you need to ensure is that FGRPB1G work is allowed in your preferences.
At the moment, as advised in this Tech News thread, there is a shortage of FGRPB1G work. For the last week or so, I've been noticing that FGRPB1G work requests can often result in "no tasks available" responses. However, followup requests often receive tasks.
If you have both GPU searches enabled, you'll get the BRP7 tasks rather than the "no tasks available" message. At the moment, my hosts requesting FGRPB1G work are managing to get it eventually, despite having to make additional requests. I suspect that may change if the situation deteriorates.
Here are the critical points (for you) for what the "unknown application" message is all about:-
It is not an error or problem message. You should just ignore it. It is just information.
It will be issued irrespective of whether or not a physical copy of the app exists on your host.
It is caused (in your case) because the name exists in your app_config.xml file but not (yet) in client_state.xml.
When the server sends you some FGRPB1G work, it will also update client_state.xml.
At that point there will be no further "unknown application" messages.
You stated earlier that you "detached and re-attached". That is probably why the known apps disappeared from your client_state.xml.
If a physical copy of the FGRPB1G app doesn't exist, the scheduler will always send a fresh copy with the FGRPB1G tasks.
In case you missed it, there is no damn problem (for you) with "unknown application" :-).
On a separate issue, if you are still seeing the "you are attached twice" messages, you should just follow Keith's advice to "edit the two files". Just do the following:-
Stop the boinc client.
Using a 'plain text' editor, edit the files client_state.xml and account_einstein.phys.uwm.edu.xml.
Look for the <master_url> ... </master_url> entry for the einstein project in each one.
Change the 'http:' bit into 'https:' by adding the 's'.
As long as the scientific application still resides in the project directory, the app_config can't complain about the missing application. But you have to have run some of the work that the application is meant for and received the app at least once.
I think you may be referring to problems with app_info.xml rather than the app_config.xml file that Mike is using. You certainly must have an existing copy if you want to use the very different beast - app_info.xml - because the scheduler doesn't have a copy of your 'special' app to send to you.
To use the app_config.xml mechanism, it doesn't change anything if you do or don't initially have a physical copy of the app. The scheduler will solve that when it first (or next) sends some work for that app.
Known apps are those for which there is an existing <app> ... </app> clause already in the state file. Launching the boinc client with an app_config.xml file specifying that app but with no existing information in the form of that <app> ... </app> clause, causes the client to just note that the app is "unknown" - for the moment. It becomes "known" the first time work is sent for that app because the information for the <app> clause comes in the scheduler reply (together with a download of the app if necessary).
I've seen this zillions of times with my hosts. When I restart a host after a break and with a dummy state file containing no <app> clauses, the client always comments that what ever apps are listed in app_config.xml are "unknown". The very first successful work fetch instantly makes the apps "known". Physically, copies of the apps were always in the einstein project directory all the time. I pre-populate that directory to save unnecessary downloads of both apps and large data files.
If the message persists, it is possible that the user may have made a typo in specifying the app short name when creating the app_config.xml file. I have made that mistake myself and have immediately realised that there must be such a typo. That's why the message is useful information.
Getting the stock BRP7 app added to my app_info was difficult for me. Never had any issues before when supplying a properly implemented app_info. It just sees a app_info file and the name of the application and it downloads the required app and the work starts.
But for some reason this time, it would not work, It kept deleting the application. So had to save a copy of the app outside of the BOINC directory for subsequent retries.
Finally solved the issue by adding the app into the client_state file ahead of asking for work and then things worked correctly.
Don't know why in this instance the first running of the app_info didn't get the stock application as it should.
Anyway, I have Petri's new BRP7 application to replace the stock app in my app_info. Will tackle that tomorrow morning.
Keith I couldn't find any
)
Keith I couldn't find any mismatch in the file names. Or typos like I posted myself
here. But what Mikey wrote seems to be the issue. If it's not running on your box, it
can't be found. Makes sense. I'm not sure what you have to do to encourage the
hsgamma_FGRPB1G 1.18 work units. Outside of selecting them on your project
preference page. "Gamma-ray pulsar binary search #1 (GPU)" . And the luck of the draw.
-Mike
As long as the scientific
)
As long as the scientific application still resides in the project directory, the app_config can't complain about the missing application. But you have to have run some of the work that the application is meant for and received the app at least once.
But if you cause the application to be deleted from the client_state files by injudicous meddling around in files, the application can be deleted from your project folder and then the error message from the app_info file can kick back in because the app is no longer resident.
If you are trying to get work for a new app you copy the science app to directory outside of BOINC so it can't delete the copy of the app so that you can retry editing of files. Or you can mark the application immutable so that neither BOINC or the system is able to delete it.
I had to do that for the BRP7 application that I was adding to my app_info to run alongside the Petri FGRPB1G application. I dumped work a couple of times and endured some 24 hour timeouts until I got the edits correct in the app_info and client_state files.
Mike wrote: ... If it's not
)
Unfortunately, the 'not running' bit has nothing to do with the 'problem' of not getting work. In fact there is no such 'problem' that requires you to do anything. To get FRGPB1G work, all you need to ensure is that FGRPB1G work is allowed in your preferences.
At the moment, as advised in this Tech News thread, there is a shortage of FGRPB1G work. For the last week or so, I've been noticing that FGRPB1G work requests can often result in "no tasks available" responses. However, followup requests often receive tasks.
If you have both GPU searches enabled, you'll get the BRP7 tasks rather than the "no tasks available" message. At the moment, my hosts requesting FGRPB1G work are managing to get it eventually, despite having to make additional requests. I suspect that may change if the situation deteriorates.
Here are the critical points (for you) for what the "unknown application" message is all about:-
On a separate issue, if you are still seeing the "you are attached twice" messages, you should just follow Keith's advice to "edit the two files". Just do the following:-
Hope this helps.
Cheers,
Gary.
Keith Myers wrote:As long as
)
I think you may be referring to problems with app_info.xml rather than the app_config.xml file that Mike is using. You certainly must have an existing copy if you want to use the very different beast - app_info.xml - because the scheduler doesn't have a copy of your 'special' app to send to you.
To use the app_config.xml mechanism, it doesn't change anything if you do or don't initially have a physical copy of the app. The scheduler will solve that when it first (or next) sends some work for that app.
Known apps are those for which there is an existing <app> ... </app> clause already in the state file. Launching the boinc client with an app_config.xml file specifying that app but with no existing information in the form of that <app> ... </app> clause, causes the client to just note that the app is "unknown" - for the moment. It becomes "known" the first time work is sent for that app because the information for the <app> clause comes in the scheduler reply (together with a download of the app if necessary).
I've seen this zillions of times with my hosts. When I restart a host after a break and with a dummy state file containing no <app> clauses, the client always comments that what ever apps are listed in app_config.xml are "unknown". The very first successful work fetch instantly makes the apps "known". Physically, copies of the apps were always in the einstein project directory all the time. I pre-populate that directory to save unnecessary downloads of both apps and large data files.
If the message persists, it is possible that the user may have made a typo in specifying the app short name when creating the app_config.xml file. I have made that mistake myself and have immediately realised that there must be such a typo. That's why the message is useful information.
Cheers,
Gary.
Getting the stock BRP7 app
)
Getting the stock BRP7 app added to my app_info was difficult for me. Never had any issues before when supplying a properly implemented app_info. It just sees a app_info file and the name of the application and it downloads the required app and the work starts.
But for some reason this time, it would not work, It kept deleting the application. So had to save a copy of the app outside of the BOINC directory for subsequent retries.
Finally solved the issue by adding the app into the client_state file ahead of asking for work and then things worked correctly.
Don't know why in this instance the first running of the app_info didn't get the stock application as it should.
Anyway, I have Petri's new BRP7 application to replace the stock app in my app_info. Will tackle that tomorrow morning.