解决常见 LSF 问题

发生错误时， LSF 服务器守护程序会在 LSF 日志目录中记录错误消息 (由 lsf.conf 文件中的 LSF_LOGDIR 参数指定)。

大多数 LSF 问题的常规故障诊断步骤。

1. 运行 lsadmin ckconfig -v 命令并记录命令输出中显示的任何错误。
   请在本节中描述的其中一个问题中查找错误。 如果这些故障诊断步骤都不适用于您的情况，请联系 IBM 支持人员。
2. 使用以下命令来重新启动 LSF 集群:

   # bctrld restart lim all
   # bctrld restart res all
   # bctrld restart sbd all

3. 运行 ps -ef 命令以查看 LSF 守护程序是否正在运行。
   查找类似于以下命令输出的进程:

   root 17426     1  0   13:30:40 ?    0:00 /opt/lsf/cluster1/10.1.0/sparc-sol10/etc/lim
   root 17436     1  0   13:31:11 ?    0:00 /opt/lsf/cluster1/10.1.0/sparc-sol10/etc/sbatchd
   root 17429     1  0   13:30:56 ?    0:00 /opt/lsf/cluster1/10.1.0/sparc-sol10/etc/res

4. 检查 LSF_CONFDIR/lsf.cluster.cluster_name 文件的 Host 部分中列出的前几个主机上的 LSF 错误日志。
   如果在 LSF_CONFDIR/lsf.conf 文件中定义了 LSF_MASTER_LIST 参数，请改为检查此参数中列出的主机上的错误日志。

当您运行 lsid 文件时，可能会看到此消息。 此消息通常表示 LSF无法访问 LSF_CONFDIR/lsf.conf 文件。

• 确保存在从 /etc/lsf.conf 到 lsf.conf的符号链接
• 使用 csrhc.lsf 或 profile.lsf 脚本来设置 LSF 环境。
• 确保 cshrc.lsf 或 profile.lsf 脚本可供用户设置 LSF 环境变量。

当 LSF LIM 守护程序意外退出时，请检查 LIM 配置文件中是否存在错误。

有时 LIM 已启动，但运行 lsload 命令会显示Communication time out。

有时 management host LIM 已启动，但运行 lsload 或 lshosts 命令会显示Master LIM is down; try later.消息。

127.0.0.1   localhost   myhostname

127.0.0.1    localhost
192.168.123.123   myhostname

::1    localhost ipv6-localhost ipv6-loopback 
 
fe00::0     ipv6-localnet 
 
ff00::0     ipv6-mcastprefix
ff02::1     ipv6-allnodes
ff02::2     ipv6-allrouters
ff02::3     ipv6-allhosts

如果远程主机无法安全地确定请求远程执行的用户的用户标识，那么远程执行将失败User permission denied。

1. 请检查远程主机上的 RES 错误日志以获取更详细的错误消息。
2. 如果不想配置标识守护程序 ( lsf.conf中的LSF_AUTH ) ，那么执行远程执行的所有应用程序都必须由具有 setuid 位集的 root 用户拥有。 运行 chmod 4755 filename 命令。
3. 如果应用程序二进制文件位于 NFS安装的文件系统上，请确保未使用 nosuid 标志安装该文件系统。
4. 如果您正在使用标识守护程序 ( lsf.conf 文件中的 LSF_AUTH 参数) ，那么必须配置 inetd 守护程序。 不能直接运行标识守护程序。
5. 名称服务器中与 /etc/hosts 和 /etc/hosts.equiv 不一致的主机名也可能导致此问题。 如果在 lsf.conf 文件中定义了 LSF_USE_HOSTEQUIV 参数，请检查目标主机上的 /etc/hosts.equiv 文件或 HOME/.rhosts 文件中是否包含客户机主机名。
6. 对于 Windows 主机，用户必须使用 lspasswd 命令注册和更新其 Windows 密码。 密码必须为 3 个字符或更长， 31 个字符或更少。

   对于非共享文件系统环境中的 Windows 密码认证，必须在 lsf.conf 文件中定义参数 LSF_MASTER_LIST ，以便作业以正确的许可权运行。 如果未定义此参数，那么 LSF 假定集群使用共享文件系统环境。

非统一文件名空间可能导致命令失败，chdir(...) failed: no such file or directory消息。

• 如果目录存在，但映射到远程主机上的其他名称，那么必须创建符号链接以使其一致。
• LSF 可以使用 automount来解决大多数 (但并非所有) 问题。 必须通过 NIS 管理自动安装映射。

  如果您正在运行自动安装，并且 LSF 无法在远程主机上找到目录，请联系 IBM 支持人员。

当 LSF 批处理守护程序 sbatchd 和 mbatchd 意外退出时，请检查配置文件中是否存在错误。

• 检查 sbatchd 和 mbatchd 守护程序错误日志。
• 运行 badmin ckconfig 命令以检查配置。
• 在 LSF 管理员邮箱中检查电子邮件。

当 sbatchd 守护程序启动但 mbatchd 守护程序未运行时， mbatchd 可能暂时不可用，因为 管理 主机 LIM 暂时未知。 该sbatchd: unknown service 将显示错误消息。

1. 运行 lsid 命令以检查 LIM 是否正在运行。
   如果 LIM 未正常运行，请遵循以下主题中的步骤来解决 LIM 问题:

   • LIM 悄然逝去
   • LIM 通信超时
   • 管理主机 LIM 已停机
2. 检查是否正确注册了服务。

LSF 使用进程组来跟踪作业的所有进程。 但是，如果应用程序派生了子代，那么该子代将成为新的进程组。 父进程将立即终止，并且子进程组将与父进程孤立，并且无法跟踪。

1. 启动作业时，应用程序将在作业 RES 或根进程组下运行。
2. 如果应用程序创建新的进程组，并且其父进程标识 (PPID) 仍属于该作业，那么 PIM 可以在该作业中跟踪此新进程组。

   不丢失进程跟踪的唯一可靠方法是防止它使用新的进程组。 当子进程与父进程组成为孤线程时，任何使其自身化的进程都将丢失，因为它会在拆离后立即更改其进程组。

mbatchd 守护程序允许 sbatchd 守护程序仅在 lsb.hosts 文件的 Host 部分中列出的主机上运行。 如果在以下配置中配置未知主机，那么 mbatchd 会记录错误消息: HostGroup 或 lsb.hosts 文件的 HostPartition 部分，或者作为 lsb.queues 文件中队列的 HOSTS 定义。

mbatchd on host: LSB_CONFDIR/cluster1/configdir/file(line #): Host hostname is not used by lsbatch; ignored

• 将未知主机添加到 lsb.hosts 文件的 Host 部分中的主机列表。
• 在新主机上启动 LSF 守护程序。
• 运行以下命令以重新配置集群:

  lsadmin reconfig
  badmin reconfig

模型或类型 UNKNOWN 指示主机已关闭或主机上的 LIM 已关闭。 您需要立即执行操作以在 UNKNOWN 主机上重新启动 LIM 。

1. 启动主机。
2. 运行 lshosts 命令以查看具有 UNKNOWN 主机类型或型号的主机。

   lshosts
   HOST_NAME  type       model   cpuf   ncpus  maxmem   maxswp  server   RESOURCES 
   hostA   UNKNOWN      Ultra2   20.2       2    256M    710M      Yes   ()

3. 运行 bctrld start lim 命令以在主机上启动 LIM :

   bctrld start lim hostA
   Starting up LIM on <hostA> .... done
   

   如果在 LSF 集群中启用了 EGO ，那么可以改为运行以下命令:

   egosh ego start lim hostA
   Starting up LIM on <hostA> .... done

   可以指定多个主机名以在多个主机上启动 LIM 。 如果未指定主机名，那么将在提交命令的主机上启动 LIM 。

   要在 UNIX 或 Linux上远程启动 LIM ，您必须是 root 用户或列示在 lsf.sudoers 文件中 (如果在 LSF 集群中启用了 EGO ，那么必须是 ego.sudoers 文件)。 您必须能够在所有主机上运行 rsh 命令，而无需输入密码。

4. 等待几秒钟，然后再次运行 lshosts 命令。

   lshosts 命令显示主机或 DEFAULT的特定模型或类型。 如果看到 DEFAULT，那么意味着自动检测主机类型或模型失败，并且找不到 lsf.shared 文件中配置的主机类型。 LSF 在主机上工作，但由于 CPU 因子不正确， DEFAULT 模型可能效率低下。 DEFAULT 类型还可能导致二进制不兼容，因为可以将来自 DEFAULT 主机类型的作业迁移到其他 DEFAULT 主机类型。

如果在 lim -t中看到 DEFAULT ，那么意味着自动检测主机类型或模型失败，并且找不到 lsf.shared 文件中配置的主机类型。 LSF 在主机上工作，但由于 CPU 因子不正确， DEFAULT 模型可能效率低下。 DEFAULT 类型还可能导致二进制不兼容，因为可以将来自 DEFAULT 主机类型的作业迁移到其他 DEFAULT 主机类型。

1. 运行 lshosts 命令以查看哪个主机具有 DEFAULT 主机模型或类型。

   lshosts
   HOST_NAME     type    model     cpuf   ncpus  maxmem  maxswp   server  RESOURCES 
   hostA     DEFAULT  DEFAULT        1       2    256M   710M       Yes  ()

   如果在使用 lshosts 命令时 Model 或 Type 显示为 DEFAULT ，并且启用了自动主机模型和类型检测，那么可以将其保留为现状或进行更改。

   如果主机型号为 DEFAULT，那么 LSF 正常工作，但主机的 CPU 系数为 1 ，这可能无法有效使用主机型号。

   如果主机类型为 DEFAULT，那么可能存在二进制不兼容性。 例如，如果一个主机是 Linux ，另一个主机是 AIX，但这两个主机都设置为类型 DEFAULT，那么可以将 Linux 主机上运行的作业迁移到 AIX 主机，或者可以将运行 AIX 主机的作业迁移到 Linux 主机，这可能会导致作业失败。

2. 在类型为 DEFAULT的主机上运行 lim -t :

   lim -t
   Host Type             : NTX64
   Host Architecture     : EM64T_1596
   Total NUMA Nodes      : 1
   Total Processors      : 2
   Total Cores           : 4
   Total Threads         : 2
   Matched Type          : NTX64
   Matched Architecture  : EM64T_3000
   Matched Model         : Intel_EM64T
   CPU Factor            : 60.0

   注: HostType 和 Host Architecture的值。
3. 编辑 lsf.shared 文件以配置主机类型和主机模型。
   1. 在 HostType 部分中，输入新的主机类型。 使用通过 lim -t 命令检测到的主机类型名称。

      Begin HostType
      TYPENAME 
      DEFAULT 
      CRAYJ
      NTX64
      ...
      End HostType

   2. 在 HostModel 部分中，输入具有体系结构和 CPU 因子的新主机模型。 使用通过 lim -t 命令检测到的体系结构。 将主机模型添加到主机模型列表的末尾。 主机模型条目的限制为 127。 使用 # 注释掉的行不会计入 127 行限制中。

      Begin HostModel
      MODELNAME   CPUFACTOR     ARCHITECTURE # keyword
      Intel_EM64T      20             EM64T_1596
      End HostModel

4. 保存对 lsf.shared 文件所作的更改。
5. 运行 lsadmin reconfig 命令以重新配置 LIM。
6. 请等待几秒钟，然后再次运行 lim -t 命令以检查主机的类型和型号。