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
...）。
扫一扫
1万+
评论 1
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
添加红包
