ports/openmpi
ports/openmpi
1
1
Форкнуть 0
Код Релизы Активность
781caee0b6
openmpi/orte/mca/plm/base/help-plm-base.txt

142 строки
5.0 KiB
Plaintext
Исходник Обычный вид История

Add a friendly help message if no pls components are found to be available. This commit was SVN r8594.
2005-12-22 17:29:45 +03:00
# -*- text -*-
#
Change the behavior of orterun (mpirun, mpirexec) to search for argv[0] and the cwd on the target node (i.e., the node where the executable will be running in all systems except BProc, where the searches are run on the node where orterun is invoked). - fork pls now does cwd and argv[0] search in orted - bproc pls does cwd and argv[0] search in orterun - cwd behavior slightly different: - if user specifies a -wdir to orterun, we chdir() to there; if we can't for some reason, abort - if user does not specify a -wdir, try to chdir() to the dir where orterun was invoked. If we can't for some reason (e.g., it doesn't exist on the target node), then try to chdir($HOME). If we can't do that, then just live with whatever default directory we were put in. This commit was SVN r9068.
2006-02-16 23:40:23 +03:00
# Copyright (c) 2004-2006 The Trustees of Indiana University and Indiana
Add a friendly help message if no pls components are found to be available. This commit was SVN r8594.
2005-12-22 17:29:45 +03:00
# University Research and Technology
# Corporation. All rights reserved.
And ORTE is ready for prime-time. All Windows tricks are in: - use the OPAL functions for PATH and environment variables - make all headers C++ friendly - no unamed structures - no implicit cast. Plus a full implementation for the orte_wait functions. This commit was SVN r11347.
2006-08-23 07:32:36 +04:00
# Copyright (c) 2004-2006 The University of Tennessee and The University
Add a friendly help message if no pls components are found to be available. This commit was SVN r8594.
2005-12-22 17:29:45 +03:00
# of Tennessee Research Foundation. All rights
# reserved.
# Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
# University of Stuttgart. All rights reserved.
# Copyright (c) 2004-2005 The Regents of the University of California.
# All rights reserved.
# $COPYRIGHT$
#
# Additional copyrights may follow
#
# $HEADER$
#
[no-available-pls]
No available launching agents were found.
This is an unusual error; it means that Open RTE was unable to find
And ORTE is ready for prime-time. All Windows tricks are in: - use the OPAL functions for PATH and environment variables - make all headers C++ friendly - no unamed structures - no implicit cast. Plus a full implementation for the orte_wait functions. This commit was SVN r11347.
2006-08-23 07:32:36 +04:00
any mechanism to launch proceses, and therefore is unable to start the
process(es) required by your application.
Bring in an updated launch system for the orteds. This commit restores the ability to execute singletons and singleton comm_spawn, both in single node and multi-node environments. Short description: major changes include - 1. singletons now fork/exec a local daemon to manage their operations. 2. the orte daemon code now resides in libopen-rte 3. daemons no longer use the orte triggering system during startup. Instead, they directly call back to their parent pls component to report ready to operate. A base function to count the callbacks has been provided. I have modified all the pls components except xcpu and poe (don't understand either well enough to do it). Full functionality has been verified for rsh, SLURM, and TM systems. Compile has been verified for xgrid and gridengine. This commit was SVN r15390.
2007-07-12 23:53:18 +04:00
#
[daemon-died-no-signal]
Cleanly handle the failed start of an orted, or its unexpected failure after start. This commit will allow mpirun to exit cleanly when this occurs, and does a best-effort attempt to cleanup the mess. However, it still has two unresolved issues that need to be eventually addressed: 1. it depends upon the ability of the native environment to alert us that the orted has died/failed to start. I have included that support for SLURM, but other environments need to be done. 2. for some yet-to-be-determined reason, the message that tells the remaining daemons to "die" isn't getting out of the RML, even though no obvious blockage is standing in the way. Work will continue on resolving that problem. For now, the orteds appear to be exiting on their own quite nicely when they see their HNP "lifeline" disappear. This represents the best-available fix for ticket #221 so I am closing that ticket at this time. This commit was SVN r18536.
2008-05-29 17:38:27 +04:00
A daemon (pid %s) died unexpectedly with status %d while attempting
Cleanup recursions in ORTE caused by processing recv'd messages that can cause the system to take action resulting in receipt of another message. Basically, the method employed here is to have a recv create a zero-time timer event that causes the event library to execute a function that processes the message once the recv returns. Thus, any action taken as a result of processing the message occur outside of a recv. Created two new macros to assist: ORTE_MESSAGE_EVENT: creates the zero-time event, passing info in a new orte_message_event_t object ORTE_PROGRESSED_WAIT: while waiting for specified conditions, just calls progress so messages can be recv'd. Also fixed the failed_launch function as we no longer block in the orted callback function. Updated the error messages to reflect revision. No change in API to this function, but PLM "owners" may want to check their internal error messages to avoid duplication and excessive output. This has been tested on Mac, TM, and SLURM. This commit was SVN r17647.
2008-02-28 22:58:32 +03:00
to launch so we are aborting.
There may be more information reported by the environment (see above).
This may be because the daemon was unable to find all the needed shared
libraries on the remote node. You may set your LD_LIBRARY_PATH to have the
location of the shared libraries on the remote nodes and this will
automatically be forwarded to the remote nodes.
#
[daemon-died-signal-core]
Cleanly handle the failed start of an orted, or its unexpected failure after start. This commit will allow mpirun to exit cleanly when this occurs, and does a best-effort attempt to cleanup the mess. However, it still has two unresolved issues that need to be eventually addressed: 1. it depends upon the ability of the native environment to alert us that the orted has died/failed to start. I have included that support for SLURM, but other environments need to be done. 2. for some yet-to-be-determined reason, the message that tells the remaining daemons to "die" isn't getting out of the RML, even though no obvious blockage is standing in the way. Work will continue on resolving that problem. For now, the orteds appear to be exiting on their own quite nicely when they see their HNP "lifeline" disappear. This represents the best-available fix for ticket #221 so I am closing that ticket at this time. This commit was SVN r18536.
2008-05-29 17:38:27 +04:00
A daemon (pid %s) died unexpectedly on signal %d (with core) while
Cleanup recursions in ORTE caused by processing recv'd messages that can cause the system to take action resulting in receipt of another message. Basically, the method employed here is to have a recv create a zero-time timer event that causes the event library to execute a function that processes the message once the recv returns. Thus, any action taken as a result of processing the message occur outside of a recv. Created two new macros to assist: ORTE_MESSAGE_EVENT: creates the zero-time event, passing info in a new orte_message_event_t object ORTE_PROGRESSED_WAIT: while waiting for specified conditions, just calls progress so messages can be recv'd. Also fixed the failed_launch function as we no longer block in the orted callback function. Updated the error messages to reflect revision. No change in API to this function, but PLM "owners" may want to check their internal error messages to avoid duplication and excessive output. This has been tested on Mac, TM, and SLURM. This commit was SVN r17647.
2008-02-28 22:58:32 +03:00
attempting to launch so we are aborting.
There may be more information reported by the environment (see above).
Bring in an updated launch system for the orteds. This commit restores the ability to execute singletons and singleton comm_spawn, both in single node and multi-node environments. Short description: major changes include - 1. singletons now fork/exec a local daemon to manage their operations. 2. the orte daemon code now resides in libopen-rte 3. daemons no longer use the orte triggering system during startup. Instead, they directly call back to their parent pls component to report ready to operate. A base function to count the callbacks has been provided. I have modified all the pls components except xcpu and poe (don't understand either well enough to do it). Full functionality has been verified for rsh, SLURM, and TM systems. Compile has been verified for xgrid and gridengine. This commit was SVN r15390.
2007-07-12 23:53:18 +04:00
This may be because the daemon was unable to find all the needed shared
libraries on the remote node. You may set your LD_LIBRARY_PATH to have the
location of the shared libraries on the remote nodes and this will
automatically be forwarded to the remote nodes.
#
[daemon-died-signal]
Cleanly handle the failed start of an orted, or its unexpected failure after start. This commit will allow mpirun to exit cleanly when this occurs, and does a best-effort attempt to cleanup the mess. However, it still has two unresolved issues that need to be eventually addressed: 1. it depends upon the ability of the native environment to alert us that the orted has died/failed to start. I have included that support for SLURM, but other environments need to be done. 2. for some yet-to-be-determined reason, the message that tells the remaining daemons to "die" isn't getting out of the RML, even though no obvious blockage is standing in the way. Work will continue on resolving that problem. For now, the orteds appear to be exiting on their own quite nicely when they see their HNP "lifeline" disappear. This represents the best-available fix for ticket #221 so I am closing that ticket at this time. This commit was SVN r18536.
2008-05-29 17:38:27 +04:00
A daemon (pid %s) died unexpectedly on signal %d while attempting to
Bring in an updated launch system for the orteds. This commit restores the ability to execute singletons and singleton comm_spawn, both in single node and multi-node environments. Short description: major changes include - 1. singletons now fork/exec a local daemon to manage their operations. 2. the orte daemon code now resides in libopen-rte 3. daemons no longer use the orte triggering system during startup. Instead, they directly call back to their parent pls component to report ready to operate. A base function to count the callbacks has been provided. I have modified all the pls components except xcpu and poe (don't understand either well enough to do it). Full functionality has been verified for rsh, SLURM, and TM systems. Compile has been verified for xgrid and gridengine. This commit was SVN r15390.
2007-07-12 23:53:18 +04:00
launch so we are aborting.
Cleanup recursions in ORTE caused by processing recv'd messages that can cause the system to take action resulting in receipt of another message. Basically, the method employed here is to have a recv create a zero-time timer event that causes the event library to execute a function that processes the message once the recv returns. Thus, any action taken as a result of processing the message occur outside of a recv. Created two new macros to assist: ORTE_MESSAGE_EVENT: creates the zero-time event, passing info in a new orte_message_event_t object ORTE_PROGRESSED_WAIT: while waiting for specified conditions, just calls progress so messages can be recv'd. Also fixed the failed_launch function as we no longer block in the orted callback function. Updated the error messages to reflect revision. No change in API to this function, but PLM "owners" may want to check their internal error messages to avoid duplication and excessive output. This has been tested on Mac, TM, and SLURM. This commit was SVN r17647.
2008-02-28 22:58:32 +03:00
There may be more information reported by the environment (see above).
Bring in an updated launch system for the orteds. This commit restores the ability to execute singletons and singleton comm_spawn, both in single node and multi-node environments. Short description: major changes include - 1. singletons now fork/exec a local daemon to manage their operations. 2. the orte daemon code now resides in libopen-rte 3. daemons no longer use the orte triggering system during startup. Instead, they directly call back to their parent pls component to report ready to operate. A base function to count the callbacks has been provided. I have modified all the pls components except xcpu and poe (don't understand either well enough to do it). Full functionality has been verified for rsh, SLURM, and TM systems. Compile has been verified for xgrid and gridengine. This commit was SVN r15390.
2007-07-12 23:53:18 +04:00
This may be because the daemon was unable to find all the needed shared
libraries on the remote node. You may set your LD_LIBRARY_PATH to have the
location of the shared libraries on the remote nodes and this will
automatically be forwarded to the remote nodes.
Merge the ORTE devel branch into the main trunk. Details of what this means will be circulated separately. Remains to be tested to ensure everything came over cleanly, so please continue to withhold commits a little longer This commit was SVN r17632.
2008-02-28 04:57:57 +03:00
#
[incomplete-exit-cmd]
One or more daemons could not be ordered to exit. This can be caused by a
number of rather rare problems, but typically is caused by a daemon having
died due to the failure of a node or its communications. This could result
in an incomplete cleanup on the affected nodes. Please see below for a list
of nodes which may require additional cleanup.
We are truly sorry for the inconvenience.
#
[incomplete-kill-procs-cmd]
One or more daemons could not be ordered to kill their local processes.
This can be caused by a number of rather rare problems, but typically
is caused by a daemon having died due to the failure of a node or its
communications. This could result in an incomplete cleanup on the affected
nodes. Additional information may be available below.
We are truly sorry for the inconvenience.
Add sanity check to ensure that specified stdin target is within range of job. Print error message and exit if not. Modify read_write test to allow specification of rank to read stdin. IOF now validated to work for arbitrary rank as stdin target. Not validate to work for multiple simultaneous ranks reading stdin (untested). This commit was SVN r19804.
2008-10-25 18:38:06 +04:00
#
[stdin-target-out-of-range]
The requested stdin target is out of range for this job - it points
Minor update - provide one more helpful hint regarding stdin target out-of-range, ensure we exit cleanly since daemons won't have been launched. This commit was SVN r19847.
2008-10-29 19:00:48 +03:00
to a process rank that is greater than the number of processes in the
Add sanity check to ensure that specified stdin target is within range of job. Print error message and exit if not. Modify read_write test to allow specification of rank to read stdin. IOF now validated to work for arbitrary rank as stdin target. Not validate to work for multiple simultaneous ranks reading stdin (untested). This commit was SVN r19804.
2008-10-25 18:38:06 +04:00
job.
Specified target: %s
Number of procs: %s
This could be caused by specifying a negative number for the stdin
Minor update - provide one more helpful hint regarding stdin target out-of-range, ensure we exit cleanly since daemons won't have been launched. This commit was SVN r19847.
2008-10-29 19:00:48 +03:00
target, or by mistyping the desired rank. Remember that MPI ranks begin
with 0, not 1.
Please correct the cmd line and try again.
Cleanup debug by converting to show_help, little more work to cleanup local vs remote ops when no preload is specified This commit was SVN r20506.
2009-02-10 22:11:24 +03:00
#
[too-many-hosts]
A call was made to launch a local slave process, but more than one
target host was provided. Currently, each launch of a local slave
can only be to a single host. To launch slaves on multiple hosts,
you must issue one call/host.
Num hosts specified: %d
#
[abs-path-reqd]
A call was made to launch a local slave process that requested the
binaries be pre-positioned on the remote host. However, an absolute
path to the target directory was either not specified, or was provided
in a relative path format.
Path provided: %s
The path to the target directory must be given as an absolute path. The
target directory does NOT need to exist - the path to the target will
be created, if required.
#
[exec-not-found]
A call was made to launch a local slave process, but the specified
executable could not be found:
Exec: %s
Please either specify an absolute path to the executable, or check
that the executable is in your PATH.
#
[cp-not-found]
A call was made to launch a local slave process that requested the
binaries be pre-positioned on the remote host. However, we could not
find the %s command in your path.
Please check that %s is in your PATH and try again.
Add ability for local slave spawns to pre-position supporting files. Update comm_spawn and comm_spawn_multiple man pages to cover new info_keys. This commit was SVN r20527.
2009-02-12 18:56:45 +03:00
#
[file-not-found]
A call was made to launch a local slave process that requested pre-positioning
of one or more files, but the specified files could not be found:
File: %s
Source directory: %s
Please either specify an absolute path to the file, or check
that the file is in your current working directory...and ensure
that you have read permissions on the file.
Копировать постоянную ссылку