Project

General

Profile

Feature #23146

DAQInterface could provide on-demand information about individual artdaq process statuses

Added by John Freeman 3 months ago. Updated 12 days ago.

Status:
Reviewed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
08/20/2019
Due date:
% Done:

100%

Estimated time:
Experiment:
-
Co-Assignees:
Duration:

Description

During a conversation I had with Eric and Ryan Rivera yesterday concerning how the OTSDAQ framework could benefit from DAQInterface functionality, it was suggested that it would be useful if DAQInterface could provide information to the external world on-demand about what the individual artdaq process statuses are. Currently it just reports whether or not there's a problem with the individual artdaq process statuses (e.g., a transition didn't go through as expected, or a process reported Error), and it does so in a printout to stdout, which is useful for human beings, but less so for controlling programs like OTSDAQ or a Run Control.

Associated revisions

Revision 09affcb0 (diff)
Added by John Freeman 3 months ago

JCF: provide individual artdaq process states on demand

When status_with_side_effects.sh is executed (or, more generally, the
state_with_side_effects XML-RPC command is sent to DAQInterface - yes,
slightly different name than the script) DAQInterface will do the following:

It produces an ASCII file of the form /tmp/artdaq_process_states_<username>_partition<partition #>,
with a list of the existing processes and their statuses. If "debug_level" is set to 5 or higher, the
list will also appear in DAQInterface's stdout - note this very high level since the output tends to
interfere with output from DAQInterface's main thread of execution.

This commit is designed to satisfy Issue #23146

Revision 1aab2fbb (diff)
Added by John Freeman 13 days ago

JCF: Issue #23146: rename the process-query function "artdaq_process_info" and have it return the full string over XML-RPC which it also writes to /tmp/artdaq_process_info_$USER_$DAQINTERFACE_PARTITION_NUMBER

History

#1 Updated by John Freeman 3 months ago

  • % Done changed from 0 to 100
  • Status changed from New to Resolved

This Issue is ready for review using the head of feature/issue23146_artdaq_process_info, commit 09affcb0f2dc46f08db0e2d5e54f6b02dd5ea396. First, to quote the commit comment:


    JCF: provide individual artdaq process states on demand

    When status_with_side_effects.sh is executed (or, more generally, the
    state_with_side_effects XML-RPC command is sent to DAQInterface - yes,
    slightly different name than the script) DAQInterface will do the following:

    It produces an ASCII file of the form /tmp/artdaq_process_states_<username>_partition<partition #>,
    with a list of the existing processes and their statuses. If "debug_level" is set to 5 or higher, the
    list will also appear in DAQInterface's stdout - note this very high level since the output tends to
    interfere with output from DAQInterface's main thread of execution.

    This commit is designed to satisfy Issue #23146

To be concrete, sending this command to DAQInterface for me created a file called /tmp/artdaq_process_states_jcfree_partition1; an example of its contents is:

component_throws_exception Error
EventBuilder1 Running
EventBuilder2 Running
DataLogger1 Running

and another is:
component_throws_exception Initializing
EventBuilder1 Ready
EventBuilder2 Ready
DataLogger1 Ready

i.e., the format is that each artdaq process gets its own row, with its label and then it state listed.

#2 Updated by John Freeman 28 days ago

  • Status changed from Resolved to Work in progress

I'm un-resolving this issue thanks to an email Gray sent this morning in which he asked how one could find the port # of an artdaq process. Eric suggested it would be nice if this were something you could query DAQInterface about, and that appears to overlap with this Issue. So, when status_with_side_effects.sh is executed, the output could not only be each artdaq process's state, but also useful info like its host, port, subsystem...basically the info in the ranks.txt file. E.g.:

component_throws_exception at mu2edaq13:10500 (subsystem 1, rank 0) :       Initializing
EventBuilder1 at mu2edaq11:10501 (subsystem 1, rank 1):                     Ready
EventBuilder2 at mu2edaq11:10502 (subsystem 1, rank 2):                     Ready
DataLogger1 at mu2edaq11:10503 (subsystem 1, rank 3):                       Ready

#3 Updated by Eric Flumerfelt 25 days ago

Is it also possible to return this string as the XMLRPC result?

#4 Updated by John Freeman 13 days ago

  • Status changed from Work in progress to Resolved
With commit d68caf7170e2a2226399f077c78566618ce4cd0f at the head of feature/issue23146_artdaq_process_info, I'm (again) marking this issue as resolved. The following now holds:
  • Via XML-RPC, you can call a function in DAQInterface called "artdaq_process_info" which for each artdaq process will list not only its state, but also its socket, subsystem and rank. Executing artdaq_process_info.sh with the desired DAQInterface partition as argument will perform this call.
  • This info both gets saved to /tmp/artdaq_process_info_${USER}_partition${DAQINTERFACE_PARTITION_NUMBER} and is returned in string form by the XML-RPC call

#5 Updated by Eric Flumerfelt 12 days ago

  • Status changed from Resolved to Reviewed
  • Co-Assignees Eric Flumerfelt added

Code reviewed and tested. Merged into develop.



Also available in: Atom PDF