Is it possible to read stderr messages, or keep them on the system after upload and reporting.

What I want to do is read the WU report file after it is uploaded. To check if there are any messages that indicate an error.
http://www.efmer.eu/boinc/boinc_tasks/

Not using BOINC itself.

BOINC apps write the stderr messages into the slot directory while running, but they get transferred to client_state.xml when the application terminates. The slot directory is immediately cleaned for re-use - nothing available there.

Similarly, science output data files are cleaned up and unavailable as soon as the 'file upload' has completed successfully - usually a matter of seconds after the application terminates. You only get a breathing space if no internet connection is available, or networking is disabled in BOINC.

The stderr messages remain in client_state.xml, and are accessible via standard RPC calls, until the result is reported: but they are removed as soon as the report ack is received from the server. And they need to be: client_state.xml is an awkward enough construct already (and BOINC can barely cope with it): reclaiming the space is vital.

The only way of doing what you want is to use, or re-create, a tool like BoincLogX, which would monitor the files and messages in real time and transfer them to your own storage structure for subsequent inspection.

Using the still very functional BOINCview it Logs and even provides an exit status code in the Completed window, so yes think it should be possible, then for the detail visit the Result Status page on the project website.

Fred is writing his tool in a SETI context. The SETI admins are being quite tough on web-scraping at the moment (to the extent of blocking IPs), and Fred has been advised to avoid it.

Using the still very functional BOINCview it Logs and even provides an exit status code in the Completed window, so yes think it should be possible, then for the detail visit the Result Status page on the project website.

Fred is writing his tool in a SETI context. The SETI admins are being quite tough on web-scraping at the moment (to the extent of blocking IPs), and Fred has been advised to avoid it.

I try to live by the rules even the one I never heard about..

Not using BOINC itself.

BOINC apps write the stderr messages into the slot directory while running, but they get transferred to client_state.xml when the application terminates. The slot directory is immediately cleaned for re-use - nothing available there.

Similarly, science output data files are cleaned up and unavailable as soon as the 'file upload' has completed successfully - usually a matter of seconds after the application terminates. You only get a breathing space if no internet connection is available, or networking is disabled in BOINC.

The stderr messages remain in client_state.xml, and are accessible via standard RPC calls, until the result is reported: but they are removed as soon as the report ack is received from the server. And they need to be: client_state.xml is an awkward enough construct already (and BOINC can barely cope with it): reclaiming the space is vital.

The only way of doing what you want is to use, or re-create, a tool like BoincLogX, which would monitor the files and messages in real time and transfer them to your own storage structure for subsequent inspection.

But this means realtime checks and that's quite time comsuming. With a couple of 1000 WU that's almost impossible to do.
I need another way.
When a WU is ready to report all the info is in the client_state.
Is there a way to stop the reporting?
In other words is it possible to stop reporting, read the clien_state (easy) and then allow reporting again.
You could send a stop new work, but do you know a beter way.

Not using BOINC itself.

BOINC apps write the stderr messages into the slot directory while running, but they get transferred to client_state.xml when the application terminates. The slot directory is immediately cleaned for re-use - nothing available there.

Similarly, science output data files are cleaned up and unavailable as soon as the 'file upload' has completed successfully - usually a matter of seconds after the application terminates. You only get a breathing space if no internet connection is available, or networking is disabled in BOINC.

The stderr messages remain in client_state.xml, and are accessible via standard RPC calls, until the result is reported: but they are removed as soon as the report ack is received from the server. And they need to be: client_state.xml is an awkward enough construct already (and BOINC can barely cope with it): reclaiming the space is vital.

The only way of doing what you want is to use, or re-create, a tool like BoincLogX, which would monitor the files and messages in real time and transfer them to your own storage structure for subsequent inspection.

But this means realtime checks and that's quite time comsuming. With a couple of 1000 WU that's almost impossible to do.
I need another way.
When a WU is ready to report all the info is in the client_state.
Is there a way to stop the reporting?
In other words is it possible to stop reporting, read the clien_state (easy) and then allow reporting again.
You could send a stop new work, but do you know a beter way.

When a WU is ready to report all the info is in the client_state.
Is there a way to stop the reporting?
In other words is it possible to stop reporting, read the clien_state (easy) and then allow reporting again.
You could send a stop new work, but do you know a beter way.

The same information goes out in the sched_request_*.xml file, in very useful <stderr></stderr> tags, which by any means is always much smaller than the client_state.xml file is. You can read it from there.

I wouldn't interfere at any time with the working of the client, stopping reports or anything else, just for the benefit of a logging program.

---

When a WU is ready to report all the info is in the client_state.
Is there a way to stop the reporting?
In other words is it possible to stop reporting, read the clien_state (easy) and then allow reporting again.
You could send a stop new work, but do you know a beter way.

The same information goes out in the sched_request_*.xml file, in very useful <stderr></stderr> tags, which by any means is always much smaller than the client_state.xml file is. You can read it from there.

I wouldn't interfere at any time with the working of the client, stopping reports or anything else, just for the benefit of a logging program.

Thanks that looks like something usefull.

The same information goes out in the sched_request_*.xml file, in very useful <stderr></stderr> tags, which by any means is always much smaller than the client_state.xml file is. You can read it from there.

I wouldn't interfere at any time with the working of the client, stopping reports or anything else, just for the benefit of a logging program.

Thanks that looks like something usefull.

Certainly does, and the files are persistent - can be read at any time until the next scheduler request. But those requests can come in pretty quick succession - typically ~20 seconds at SETI - and no backup of the previous file is kept.

and no backup of the previous file is kept.

In that case, Fred can probably tell his program to make a backup of the sched_request_*.xml file. :-)

Something like:
- Read sched_request* file, check for <stderr> tag.
- If present, make backup with incremental number.
- Use backup to plunder for data.

---

and no backup of the previous file is kept.

In that case, Fred can probably tell his program to make a backup of the sched_request_*.xml file. :-)

Something like:
- Read sched_request* file, check for <stderr> tag.
- If present, make backup with incremental number.
- Use backup to plunder for data.

A backup was something I had in mind but there are some potential problems.
When a WU completes and is uploaded a request for more work and an report may be seconds away.
But let's see what I can do, the goal is to have less impact not more than BOINC.
I think I can go ahead with this for a couple of days....
So I can spot some errors the moment they occur.

A backup was something I had in mind but there are some potential problems.
When a WU completes and is uploaded a request for more work and an report may be seconds away.
But let's see what I can do, the goal is to have less impact not more than BOINC.
I think I can go ahead with this for a couple of days....
So I can spot some errors the moment they occur.

Knowing some BOINC quirks may help you here.

If the application exits with an error, I think you get an automatic comms backoff of 60 seconds, so no immediate sched_request. There's usually no upload file for an exit_error, so the error text will definitely be in the next sched_request, which as you say is likely to be pretty soon after the 60 seconds are up.

If the application exits early, but reports success - e.g. a SETI dash-9 overflow - then as you say the cache/EDF recalculation may trigger an immediate work fetch: but there will be a file to upload, and the upload won't be complete when the sched_request goes in. So the error text won't appear until the next sched_request, or possibly even later if the upload handler is playing up.

Oeps another thing I forgot to ask.
I want to do this remotely.
Is there a way to read a file by using the Boinc core client.
So an RPC read on a specific XML file on a remote computer.

Not without you sharing that computer's BOINC Data directory (and underlying files and maps) with the other computers on the network.

---