# -*- text -*-
#
# Copyright (c) 2018      Research Organization for Information Science
#                         and Technology (RIST).  All rights reserved.
# Copyright (c) 2019      Intel, Inc.  All rights reserved.
# Copyright (c) 2022-2024 Nanook Consulting  All rights reserved.
# $COPYRIGHT$
#
# Additional copyrights may follow
#
# $HEADER$
#
#
[bad-combination]
The runtime option NOTIFYERRORS was set to true. This requests that the
runtime provide a PMIx event whenever a job encounters an error - e.g., a
process fails. The event is to be delivered to each remaining process in
the job. However, this only can be done if the job is not to be terminated
in the event of an error. The following runtime options govern that
behavior:

    RECOVERABLE[=(bool)] if set to true, this indicates that the application
    wishes to consider the job as recoverable - i.e., the application is
    assuming responsibility for recovering from any process failure. This
    could include application-driven spawn of a substitute process or
    internal compensation for the missing process. This option defaults to
    a true value if the option is given without a value.

    CONTINUOUS[=(bool)] if set to true, this informs the runtime that the
    processes in this job are to run until explicitly terminated. Processes
    that fail are to be automatically restarted up to "max restarts"
    number of times. Notification of process failure is to be delivered
    to all processes in the application. This is the equivalent of specifying
    RECOVERABLE, NOTIFYERRORS, and AUTORESTART options except that the runtime,
    not the application, assumes responsibility for process recovery. This
    option defaults to a true value if the option is given without a value.

You must specify one of the above in combination with NOTIFYERRORS in order
to receive notifications of errors. Please correct the situation and try again.
#
[child-term]
At least one child job is being terminated due to termination of
its parent:

  Parent: %s
  Child:  %s

This behavior is controlled by setting the PMIX_SPAWN_CHILD_SEP attribute
in the job info provided at time of spawn for the child job. When set to
"true", the runtime will "separate" the child from its parent and allow
it to continue execution after parent termination. Note that this is only
true for parents that normally terminate - abnormal termination will always
result in a complete teardown of all child jobs.

In the absence of the attribute, the runtime will default to the "true"
behavior.
#
[child-job-status]
Child job %s exited with status %d.

This status is being reported on its own and does not contribute to the
exit status returned for the primary job, because the
"report-child-jobs-separately" runtime option is in effect. Remove that
option (or set it to "false") if you want the first non-zero status
returned by the primary job or any job it spawned to be reported as the
overall exit status.
#
[orphaned-proc]
%s: a process has terminated, but the runtime holds no record of the job
it belonged to:

  Process: %s

This is an internal inconsistency - the job object was released while the
job was still running, so this process's termination cannot be accounted
for and the job can never be declared complete.  Rather than wait forever
for a job it can no longer see, the runtime is bringing the DVM down once
nothing it can still account for is running.  The exit status will be
non-zero.

Please report this, with the command line that produced it, at:

  https://github.com/openpmix/prrte/issues
#
[state-log-no-path]
%s: DVM state logging was requested, but the directory to write the log
into could not be determined:

  Configured path: %s

A relative path (or no path at all) is resolved against the session
directory base - the DVMTempDir configuration key, or the
"prte_tmpdir_base" MCA parameter - and no such base is set.  Either give
an absolute path or set the session directory base.

State logging has been disabled for this process; the DVM is otherwise
proceeding normally.
#
[state-log-open-failed]
%s: DVM state logging was requested, but the log could not be opened:

  Location: %s
  Error:    %s

Check that the path exists, is a directory, and is writable by the user
this daemon is running as.

State logging has been disabled for this process; the DVM is otherwise
proceeding normally.
