Sun Grid Engine 常见问题的错误诊断

1.  问题 — 作业的输出文件显示Warning: no access to tty; thus no job control in this shell...。
    可能的原因 — 一个或多个登录文件中包含stty 命令。只有存在终端时，这些命令才有用。
    可能的解决方法 — 不要将终端与批量作业相关联。必须从登录文件中删除所有的
      stty 命令，或用if 语句将这些命令包括起来。处理if 语句前应该检查终端。
     下例显示了一个if 语句：
      /bin/csh:
      stty -g                                  # checks terminal status
      if ($status == 0)                   # succeeds if a
      terminal is present
      <put all stty commands in here>
      endif

2. 问题 — 作业标准错误日志文件显示‘tty‘:Ambiguous。但是在作业脚本所调用的用户shell 中不存在对tty 的引用。
    可能的原因 — 默认情况下，shell_start_mode 为posix_compliant。因此，所有的作业脚本都使用在队列定义中指
                          定的shell 运行。而不使用在作业脚本的第一行中指定的shell 运行。
    可能的解决方法 — 使用qsub 命令的-S 标志，或将shell_start_mode 更改为unix_behavior。

3. 问题 — 可从命令行运行作业脚本，但是当使用qsub 命令运行该作业脚本时它会失败。
   可能的原因 — 可能为作业设置了进程限制。要测试是否测试了限制，请编写一个执行limit 和limit -h 功能的测试脚
                         本。在shell 提示符下使用qsub 命令交互运行这两个功能，然后比较其结果。
   可能的解决方法 — 删除（在shell 中设置限制的）配置文件中的所有命令。

4. 问题 — 执行主机报告的负荷为99.99。
    (1). 可能的原因 — sge_execd 守护进程未在此主机上运行。
           可能的解决方法 — 以root 用户的身份在执行主机上运行sge-root/cell/common/sgeexecd 脚本以启动
                                       sge_execd 守护进程。
     (2). 可能的原因 — 未正确指定默认域。
            可能的解决方法 — 以Grid Engine 系统管理员的身份运行qconf -mconf 命令，并将default_domain 变量更改
                                  为none。
      (3). 可能的原因 — sge_qmaster 主机所看到的执行主机的名称与执行主机看到的自己的名称不同。
            可能的解决方法 — 如果使用DNS 解析计算群集的主机名，请配置/etc/hosts和NIS，使其作为主要主机名称
                                    返回全称域名(FQDN) 。当然，您仍然可以定义并使用短别名（例如，168.0.0.1
                                    myhost.dom.com myhost）。如果不使用DNS，请确保所有的/etc/hosts 文件和NIS 表是一
                                   致的（例如，168.0.0.1 myhost.corp myhost 或168.0.0.1 myhost）。
5. 问题 — 每过30 秒，便有一条类似于以下的消息打印到cell/spool/host/messages中：
        Tue Jan 23 21:20:46 2001|execd|meta|W|local
         configuration meta not defined - using global configuration
        但是cell/common/local_conf 包含每个带有FQDN 的主机的文件。
  可能的原因 — 计算机meta 上的主机名解析返回的是短名称，但是主控主机上返回的是带有FQDN 的meta。
  可能的解决方法 — 请确保所有的/etc/hosts 文件和NIS 表在这方面是一致的。此例中，主机meta 的/etc/hosts 文件
                               中可能错误地包含了以下内容：
                               168.0.0.1 meta meta.your.domain
                                该行的正确内容应为：
                               168.0.0.1 meta.your.domain meta.
6. 问题 — 在守护进程的messages 文件中偶而会看到CHECKSUM ERROR、WRITE ERROR 或READ ERROR 消
                 息。
     可能的原因 — 只要这些消息出现的时间间隔大于一秒，就不需要采取任何措施。该信息典型的情况是每天出现1
                           到30 次。
7. 问题 — 在一个特定的队列中完成作业，并在qmaster/messages 中返回以下消息：
    Wed Mar 28 10:57:15 2001|qmaster|masterhost|I|job 490.1
    finished on host exechost
    然后可在执行主机中的exechost/messages 文件中看到以下错误消息：
    Wed Mar 28 10:57:15 2001|execd|exechost|E|can’t find directory
    "active_jobs/490.1" for reaping job 490.1
    Wed Mar 28 10:57:15 2001|execd|exechost|E|can’t remove directory
    "active_jobs/490.1": opendir(active_jobs/490.1) failed:
    Input/output error
   可能的原因 — 正在卸载已自动装入的sge-root 目录，从而导致sge_execd 守护进程丢失其当前工作目录。
   可能的解决方法 — 使用sge_execd 主机的本地假脱机目录。使用QMON 或qconf 命令设置参数execd_spool_dir。
8. 问题 — 用qrsh 实用程序提交交互式作业时，得到以下错误消息：

   % qrsh -l mem_free=1G error: error: no suitable queues

  但对于使用qsub 命令提交的批处理作业，队列是可用的。可使用qhost -l mem_free=1G 和qstat -f -l
  mem_free=1G 查询这些队列。
  可能的原因 — 消息error: no suitable queues 由-w e 提交选项引起，默认情况下该选项对于交互式作业（比如
                       qrsh）是活动的。请在qrsh(1) 手册页中查找-w e。如果sge_qmaster 无法根据当前的群集配置确定
                       作业是否是可分派的，则此选项将导致作业提交命令失败。该机制的目的在于提前拒绝作业的请求，
                       以防该请求无法获得准许。
  可能的解决方法 — 这种情况下，mem_free 已配置为可使用的资源，但是尚未指定每台主机可用的内存数量。执行
                       此检查时特意未考虑内存负荷值（该值不时变化）因此，内存负荷值无法视为群集配置的一部分。您
                      可以执行以下之一：
                       忽略此检查 ，通常是用-w n 选项明确地替代qrsh 的默认选项-w e。还可将此命令放入     
                                           sge-root/cell/common/sge_request 下。
                       如果希望将 mem_free 作为可使用的资源管理，请使用qconf -me
                                        hostname 在host_conf 的complex_values 中指定主机的mem_free 容量。
                     如果不希望将 mem_free 作为可使用的资源进行管理，请在complex(5) 的consumable 列中使用
                                       qconf -mc hostname 再次将其设为不可使用的资
9. 问题 — qrsh 不会分派到它所在的同一节点。从qsh shell 中可得到类似于以下的消息：
     host2 [49]% qrsh -inherit host2 hostname
     error: executing task of job 1 failed:
     host2 [50]% qrsh -inherit host4 hostname
     host4
    可能的原因 — gid_range 不够。gid_range 应定义为一个范围，而不是单个数字。Grid Engine 系统为主机上的
                        每个作业分配一个不同的gid。
    可能解决方法 — 用qconf -mconf 命令或QMON 调整gid_range。建议的范围如下：
                        gid_range     20000-20100
10. 问题 — qrsh -inherit -V 在并行作业内使用时不起作用。得到以下消息：
                cannot get connection to "qlogin_starter"
    可能的原因 — 此问题发生在嵌套调用qrsh 时。此问题由-V 选项导致。第一个qrsh -inherit 调用设置了环境变量
                        TASK_ID。TASK_ID 是并行作业中高度集成任务的ID 。第二个qrsh -inherit 调用将此环境变量用于注册其任
                        务。当命令试图启动与已经运行的首次任务具有相同ID 的任务时，该命令失败。
     可能的解决方法 — 可在调用qrsh -inherit 之前取消TASK_ID 的设置，或使用-v 选项替代-V。此选项只导出真正需要的环
                          境变量。
11. 问题 — qrsh 似乎根本不起作用。生成类似如下内容的消息：
      host2$ qrsh -verbose hostname
      local configuration host2 not defined - using global configuration
      waiting for interactive job to be scheduled ...
     Your interactive job 88 has been successfully scheduled.
     Establishing /share/gridware/utilbin/solaris64/rsh session
    to host exehost ...
    rcmd: socket: Permission denied
    /share/gridware/utilbin/solaris64/rsh exited with exit code 1
    reading exit code from shepherd ...
    error: error waiting on socket for client to connect:
    Interrupted system call
    error: error reading return code of remote command
    cleaning up after abnormal exit of
    /share/gridware/utilbin/solaris64/rsh
    host2$
    可能的原因 — 未正确设置qrsh 的权限。
    可能的解决方法 — 检查位于sge-root/utilbin/ 下的文件的权限。请注意，rlogin 和rsh 必须为setuid 且必须属于root 用户。
    -r-s--x--x 1 root root 28856 Sep 18 06:00 rlogin*
    -r-s--x--x 1 root root 19808 Sep 18 06:00 rsh*
    -rwxr-xr-x 1 sgeadmin adm 128160 Sep 18 06:00 rshd*

     注– sge-root 目录也需要使用setuid 选项的NFS 安装方式。如果sge-root 是从提交客户机用nosuid 装入的，则qrsh 和相
          关的命令将不起作用。

12. 问题 – 当尝试启动一个分布式的make 程序时，qmake 退出并显示以下错误消息：
    qrsh_starter: executing child process
    qmake failed: No such file or directory
    可能的原因 — Grid Engine 系统在执行主机上启动了一个qmake 的实例。如果未在用户的shell 资源文件（.profile 或.
                        cshrc）中设置Grid Engine 系统环境变量（尤其是PATH），则qmake 调用将失败。
     可能的解决方法 — 使用-v 选项将PATH 环境变量导出到qmake 作业。典型的qmake 调用如下：
qmake -v PATH -cwd -pe make 2-10 --

  13. 问题 — 当使用qmake 实用程序时，得到以下错误消息：
    waiting for interactive job to be scheduled ...timeout (4 s)
     expired while waiting on socket fd 5
     Your "qrsh" request could not be scheduled, try again later.
     可能的原因 — 在shell 中ARCH 环境变量设置不正确，而qmake 需要要从该shell 中调用。
     可能的解决方法 – 将ARCH 变量正确地设置为与群集中可用主机相匹配的受支持的值，或在提交时指定正确的值（例如，
                               qmake -v ARCH=solaris64
                               ...）。