1. 为什么还在用Torque项目背景与选型复盘先说点题外话。很多人一听说我要在Ubuntu 20.04上装Torque 6.1.2第一反应都是这玩意儿不是早该进博物馆了吗现在不都上Slurm了吗说实话我也知道Slurm是当前的主流但实际工作中Torque的存量市场远比大家想象的大。不少高校计算中心、企业内部的计算集群尤其是那些跑着老旧科研项目代码的机器生产环境里依然是Torque在做调度。我自己这次接手的就是一台用于分子动力学模拟计算的服务器团队里跑的东西依赖一套跟Torque绑定得很死的作业管理脚本迁移代价极大所以只能在新的Ubuntu 20.04系统上重新把Torque 6.1.2部署起来。选择6.1.2这个版本也是有讲究的。Torque在6.x系列里6.1.2算是生命周期相对稳定、社区反馈问题较少的版本。虽然它称不上完美但相比5.x版本6.1.2对现代内核的兼容性更好相比后来的6.1.3又少了一些新引入的麻烦至少在我用过的几台机器上是这样。如果你去读Torque的官方文档和邮件列表会发现6.1.2在CentOS 7和Ubuntu 18.04、20.04上的部署案例是最多的这意味着你遇到问题时更容易在历史记录里找到答案。对我这种懒人来说选一个搜索记录最多的版本本身就是一种效率策略。再说环境。这台机器是双路Xeon Gold 6248总共80个逻辑核心512GB内存系统盘是NVMe SSD数据盘是RAID阵列。操作系统是纯净的Ubuntu 20.04.3 LTS内核版本5.4.0。机器上没有装任何其他调度器也没有MariaDB之类的数据库服务整体环境相对干净。这个干净很重要因为Torque编译安装时最怕各种残留的旧版本文件干扰如果没有条件用新系统也至少要把之前装过的torque相关的包和目录清理干净后面我会专门说这个问题。这篇文章我会把所有关键步骤、我在安装过程中踩过的坑、以及每一个问题的定位和解决办法都写清楚。如果你跟我一样需要在Ubuntu 20.04上跑Torque单机版这篇文章可以直接当作业指导书用。如果你是第一次接触PBS体系我也会把相关概念讲明白尽量不让术语成为阅读障碍。2. Ubuntu 20.04环境的准备工作2.1 关闭可能冲突的组件Torque的核心功能是资源管理和作业调度它依赖端口和系统服务来运行。在Ubuntu 20.04上有几个东西可能会跟Torque打架装之前必须处理干净。首先确认系统里没有跑着其他调度器。用systemctl检查一下有没有slurmctld、slurmd这些服务如果有停掉并禁用。其次检查端口占用情况。Torque的几个主要组件默认使用的端口分别是pbs_server15001pbs_sched15004pbs_mom15002trqauthd15005在安装前用ss -tlnp检查这些端口是否被占用。我遇到过一种情况某内部监控系统占用了一个随机端口恰好在Torque的端口范围内导致pbs_server启动后通信异常。所以这个检查不能省。2.2 创建专用运行用户Torque官方文档强烈建议不要用root用户跑服务进程。这不仅仅是安全问题更是实际运行稳定性的问题。Torque的pbs_mom进程在向计算节点下发任务时需要以作业提交者的身份创建进程如果以root身份运行服务权限模型会异常甚至在某些场景下导致作业启动失败。执行以下命令创建专用用户sudo useradd -r -m -d /home/torque -s /bin/bash torque sudo passwd torque这里-r参数表示创建系统账户-m和-d参数指定家目录。我习惯给Torque用户一个可登录的shell因为在调试过程中经常需要以torque用户身份执行命令验证权限如果shell是nologin每次都得su -s /bin/bash麻烦得很。2.3 安装依赖工具链Torque 6.1.2编译需要gcc、g、make、libssl-dev等工具包。Ubuntu 20.04自带的GCC版本是9.x这个版本能不能编译Torque 6.1.2是我这次踩的第一个大坑后面会展开说。先把基础依赖装上sudo apt update sudo apt install -y build-essential libssl-dev libtool autoconf automake注意一定不要跳过libtool和autoconf。Torque的源码包里有些脚本是.m4宏生成的不同环境下需要重新生成configure脚本如果缺了这两个工具后面编译时会报出非常莫名其妙的错误而且错误信息跟真正的原因完全不搭边排查起来很浪费生命。3. 源码下载与解压一个容易犯迷糊的细节Torque的源码可以从GitHub仓库获取。需要注意官方仓库的master分支是开发版直接clone下来编译大概率会失败。我们要用的是打了tag的稳定版。这里有两个方式# 方式一下载release压缩包 wget https://github.com/adaptivecomputing/torque/archive/refs/tags/6.1.2.tar.gz tar -zxvf 6.1.2.tar.gz cd torque-6.1.2 # 方式二clone仓库后切tag git clone https://github.com/adaptivecomputing/torque.git cd torque git checkout 6.1.2我建议用方式二。因为后续如果遇到源码层面的问题需要patch时用git仓库操作起来更方便还能随时切换分支查看不同版本间的差异。我自己在编译过程中就反复用git diff对比了6.1.2和master的代码差异这帮我定位到了真正导致编译失败的问题根源。解压完成后不要急着执行configure命令。先检查一下源码目录里的README和CHANGELOG尤其是CHANGELOG里关于6.1.2版本修复了哪些bug、已知问题有哪些这些信息在官方文档里反而没写那么详细。源码里的INSTALL文件也要快速过一遍里面有些细节是网上教程不会提到的例如推荐的内核参数配置、PBS_HOME目录结构等。4. 编译期的经典踩坑GCC 9与Torque 6.1.2的爱恨情仇4.1 第一个坑GCC 9编译直接报错这是我在这次安装中遇到的最棘手的问题网上相关讨论也很多。Ubuntu 20.04系统默认的GCC版本是9.3.0而Torque 6.1.2的源码是2017年左右写的那时候主流的GCC版本是5.x、6.x。用GCC 9编译Torque会在源码的多个位置触发C标准兼容性错误。我执行configure后编译在make阶段报出了大量类似这样的错误src/lib/Libutils/uthash.h:XXX:XX: error: class std::string has no member named compare这类问题根源在于Torque 6.1.2在用C的std::string时调用了早期GCC版本允许的某些成员函数而GCC 9对C标准库的实现更加严格把这些不规范的调用全部暴露出来了。解决这个问题有两个路径路径一降级系统GCC。安装GCC 7或GCC 8并把它们设为默认编译器。这个方法最稳妥因为Torque 6.1.2在开发时代主要就用GCC 4.8到7.x做测试。但降级GCC会影响系统里其他软件包的编译环境如果你这台机器还承担着别的编译任务风险比较大。路径二修改源码。这也是我最终采用的方法。具体来说是把src/lib/Libutils/uthash.h里的问题代码做兼容性处理。不过这个修改量比较大而且不同位置的错误可能需要不同的patch策略。这里我直接给出我试验成功的方案。在configure之前先编辑src/lib/Libutils/uthash.h把其中那些使用了string::compare的调用改成string::compare重载函数的正确写法。说实话这个文件里的问题代码不止一处我当时的操作是把整个文件做了一次搜索替换把所有. compare(操作替换为正确的形式。但是这么做有一定风险因为不同上下文需要不同的替换策略建议先备份原文件再逐点修改。4.2 第二个坑OpenSSL版本不匹配Ubuntu 20.04自带OpenSSL 1.1.1系列而Torque 6.1.2通过--with-ssl选项启用加密传输时依赖OpenSSL 1.0.x的某些接口。如果在configure时显式指定--with-ssl/usr会在make时报出找不到OPENSSL_config等符号的错误。这里我建议的做法是不要显式指定--with-ssl让configure自动探测系统自带的OpenSSL。在自动探测模式下Torque 6.1.2会用较宽松的兼容逻辑来适配OpenSSL 1.1.x的部分接口虽然编译时偶尔会出现一两个警告但至少能通过。如果你对安全性要求不是极高、且只是在内网使用也可以干脆不启用SSL加密。毕竟Torque的加密传输在实际使用中的性能损耗不小对内网环境来说意义有限。4.3 第三个坑configure脚本本身的问题从GitHub下载的源码包里的configure脚本可能无法直接执行提示Permission denied或者/bin/sh^M: bad interpreter。这个问题的根源在于文件换行符在不同的打包环境下变成了CRLF。解决办法sed -i s/\r$// configure chmod x configure这两个命令几乎能解决所有由于换行符导致的执行时报错。如果你在解压目录里看到一堆后缀为.in的文件不用管它们我们只需要改顶层的configure脚本。5. 编译安装的全流程记录5.1 我的最终configure配置在经历了上述一系列问题后我最终采用的configure配置如下./configure --prefix/usr/local/torque \ --with-server-home/var/spool/torque \ --with-default-serverlocalhost \ --with-mom-log-file/var/spool/torque/mom_logs/momlog \ --with-server-log-file/var/spool/torque/server_logs/serverlog \ --with-scheduler-log-file/var/spool/torque/scheduler_logs/schedlog \ --disable-gui几个参数的说明--prefixTorque的可执行文件和库文件的安装目录。我统一放在/usr/local/torque下面方便后续管理和卸载。--with-server-homeTorque运行时的数据目录包括作业队列、节点信息、日志等都会放在这里。这个目录需要提前创建好并给torque用户读写权限。--with-default-server指定默认的调度服务器。单机模式下填localhost就行。--disable-gui不编译图形界面工具。我通过SSH操作服务器GUI没有意义还容易引入额外的依赖问题。configure执行时间大概1到2分钟。执行完毕后检查config.log里是否有error关键字特别是关于OpenSSL和C标准库的警告。如果config.log里存在无法解决的错误建议不要继续往下走先把问题解决再说。因为我发现很多人在configure阶段就出现了问题却强行make最后报出来的错误千奇百怪反而更难定位。配置成功后会看到这样一行提示Configuration complete. Type make to build TORQUE.5.2 make阶段的耐心与崩溃在GCC 9的环境下make过程总共耗时大约10分钟。期间会有大量的编译警告例如-Wdeprecated-copy、-Wclass-memaccess等这都属于GCC 9对旧代码的碎碎念不影响最终生成结果你可以忽略它们。但要特别注意如果make提前终止并输出Error 1说明仍然有编译错误需要回到上面的GCC兼容性处理章节。我第一次执行make时就是在编译src/lib/Libutils/目录下的libtorque_utils库时报错退出的。那个库是几乎所有组件的底层依赖它编译不过后面全都白搭。5.3 不要直接make install的惨痛教训官方INSTALL文档里写的安装步骤就是简单的三条make、make install、make packages。但在Ubuntu 20.04环境下直接make install会带来一个非常隐蔽的问题头文件的安装位置。Torque 6.1.2的默认头文件安装路径和Ubuntu的库搜索路径不一致这会导致后续用torque提供的开发库编写客户端程序时链接阶段找不到头文件。我建议在make install之前先做一步特殊的处理sudo mkdir -p /usr/local/include/torque sudo make installinstall完成后把生成的库文件软链到系统库目录sudo ln -sf /usr/local/torque/lib/*.so /usr/local/lib/ sudo ldconfig这也是一个容易被忽略的坑。如果你不创建这个软链后续pbs_mom运行时动态链接库会找不到libtorque.so。系统里如果有其他软件依赖Torque的库运行时会报error while loading shared libraries: libtorque.so: cannot open shared object file。6. 初始化配置三个最容易出错的配置文件6.1 /var/spool/torque目录结构与权限一切安装完成后开始初始化。我按照上面configure指定的路径手动创建了完整的数据目录结构sudo mkdir -p /var/spool/torque/server_logs sudo mkdir -p /var/spool/torque/scheduler_logs sudo mkdir -p /var/spool/torque/mom_logs sudo mkdir -p /var/spool/torque/checkpoint sudo mkdir -p /var/spool/torque/undelivered sudo chown -R torque:torque /var/spool/torque权限问题必须从一开始就处理好。很多教程跳过这一步直接以root用户运行pbs_server初始化导致生成的serverdb、nodes等文件的属主都是root。这虽然能正常工作但后续以torque用户运行pbs_server时会因为无法写入这些文件而崩溃。6.2 环境变量配置让你少走威路的PATH操作安装完成后需要把Torque的命令目录加入系统的PATH环境变量。编辑/etc/profile在文件末尾追加export PATH/usr/local/torque/bin:/usr/local/torque/sbin:$PATH export LD_LIBRARY_PATH/usr/local/torque/lib:$LD_LIBRARY_PATH export PBS_SERVERlocalhost这里特别要提醒的是PBS_SERVER环境变量。很多人在单机版上跑作业时报错说找不到服务器其实就是因为这个变量没设置。PBS命令在解析服务器地址时如果不是显式指定了-server参数就会读取环境变量PBS_SERVER。这个变量没设命令就默认找第一个字符为当前主机名的FQDN在Ubuntu上由于hostname的解析规则不同经常会出现找不到服务导致超时的情况。设置完毕后执行source /etc/profile让配置立即生效。6.3 配置nodes文件单机版的节点注册Torque的节点信息保存在/var/spool/torque/server_priv/nodes文件中。需要手动编辑这个文件将本机注册为计算节点sudo vim /var/spool/torque/server_priv/nodes文件内容写入localhost np80这里的np参数表示该节点的CPU核心数。我在初始化系统时没有设置好Hostname对应的FQDN导致pbs_server在解析这个节点名时失败。为了解决这个问题我建议在/etc/hosts里明确加一行127.0.1.1 hostname hostname.localdomain注意Ubuntu 20.04的默认/etc/hosts配置里主机名可能只关联了127.0.1.1地址。你需要确保这个地址跟你在nodes文件里写的节点名对应上否则后续提交作业时可能出现cannot determine hostname之类的错误。7. 启动链路pbs_server、pbs_sched、pbs_mom与trqauthd的启动顺序7.1 组件角色速览Torque单机版需要启动4个核心进程trqauthd认证守护进程负责客户端和服务器之间的身份验证通信。pbs_server管理守护进程保存作业队列、资源状态、服务节点的注册信息。pbs_sched调度守护进程根据策略和可用资源分配作业。pbs_mom执行守护进程在计算节点上实际启动和管理作业进程。单机环境下pbs_server和pbs_mom都在本机运行。7.2 启动顺序不能乱这些进程的启动顺序要求很严格。正确的启动顺序# 1. 先启动trqauthd sudo /usr/local/torque/sbin/trqauthd # 2. 初始化server数据库 sudo /usr/local/torque/sbin/pbs_server -t create # 3. 启动调度器 sudo /usr/local/torque/sbin/pbs_sched # 4. 启动mom执行进程 sudo /usr/local/torque/sbin/pbs_mom我第一次操作时按照网上某篇教程的顺序先启动了pbs_mom再启动pbs_server结果pbs_mom反复尝试连接服务端都失败日志里刷满Connection refused。后来才发现是顺序问题。这个顺序本质上是一个依赖链pbs_sched依赖pbs_server的节点和队列信息进行调度决策pbs_mom依赖pbs_server的注册指令来接受作业。7.3 pbs_server -t create的含义pbs_server首次启动时必须加-t create参数它的作用是创建server数据库文件。这个参数只在首次初始化时需要后续启动进程时如果还加这个参数会清空服务器数据库相当于把之前配置的队列、节点信息全格掉。这个坑特别隐蔽尤其是你把pbs_server写进systemd服务文件时千万别把这个参数写死在启动命令里。7.4 检查进程是否正常启动启动完所有组件后用ps命令检查进程状态ps aux | grep pbs ps aux | grep trq正常的进程状态应该是4个守护进程都在运行。如果某个进程反复重启就得去看对应的日志文件。日志路径就是我们在configure时指定的目录/var/spool/torque/server_logs//var/spool/torque/scheduler_logs//var/spool/torque/mom_logs/日志文件命名格式通常是日期-time.log或者server.log用tail命令实时查看tail -f /var/spool/torque/server_logs/server.log8. 队列创建与节点注册验证8.1 qmgr命令把节点加进管理范围pbs_server正常起来后需要用qmgr命令配置队列。这是Torque管理接口的核心命令。我执行的第一组命令sudo /usr/local/torque/bin/qmgr -c set server scheduling true sudo /usr/local/torque/bin/qmgr -c set server keep_completed 300 sudo /usr/local/torque/bin/qmgr -c set server query_other_jobs true sudo /usr/local/torque/bin/qmgr -c set server job_history_enable true sudo /usr/local/torque/bin/qmgr -c create queue batch queue_typeexecution sudo /usr/local/torque/bin/qmgr -c set queue batch startedtrue sudo /usr/local/torque/bin/qmgr -c set queue batch enabledtrue sudo /usr/local/torque/bin/qmgr -c set server default_queuebatch这些命令的含义依次是开启调度器、保留作业完成记录、允许查询其他用户作业、启用作业历史、创建batch执行队列、启动队列并启用队列、把batch设为默认队列。执行完这些命令后用qmgr -c print server和qmgr -c print queue batch验证配置是否正确。8.2 pbsnodes命令节点状态检查节点注册正确后用pbsnodes -a命令可以看到节点状态/usr/local/torque/bin/pbsnodes -a正常输出类似localhost state free np 80 ntype cluster status ...看到state free说明资源可用。如果state显示down或者unknow说明pbs_mom和pbs_server之间通信有问题需要检查两边的日志。我第一次启动时节点状态一直显示down排查了很久才发现是pbs_mom在启动时没有以torque用户身份运行。Torque 6.1.2的pbs_mom强制要求以非root用户运行如果直接sudo /usr/local/torque/sbin/pbs_mom启动进程会在初始化阶段自己降到torque用户权限。但如果系统里没有这个用户或者torque用户没有家目录进程就会在初始化时报错节点状态自然就是down。9. 提交测试作业从HelloWorld到资源限制9.1 第一个作业交互式与非交互式配置完成后该验证核心功能了。我写了一个最简单的测试脚本#!/bin/bash #PBS -N test_job #PBS -l nodes1:ppn4 #PBS -l walltime00:05:00 echo Hello from Torque sleep 10 hostname保存为test.sh然后使用qsub提交/usr/local/torque/bin/qsub test.shqsub返回一个作业ID格式是0.localhost可以通过qstat查看作业状态。/usr/local/torque/bin/qstat -n第一次提交作业时我发现作业状态一直停在Q排队状态不进入R运行状态。查看pbs_sched日志后发现调度器无法匹配到可用的执行节点。问题出在nodes文件里的节点名跟pbs_server解析到的主机名不一致。把/etc/hosts和nodes文件统一之后调度立刻恢复正常。9.2 常见作业错误排查我在验证过程中故意制造了一些错误场景来测试系统的稳定性这有助于发现隐藏问题。场景一提交一个请求资源超过本机核心数的作业qsub -l nodes1:ppn100 test.shTorque的调度器会正确拒绝这个作业状态变为排队不调度所有资源都被占用无法满足该作业请求时作业会一直被挂在Q状态。这是正常行为不是故障。场景二提交一个walltime格式错误的作业qsub -l walltime5 test.sh这里5会被解析为秒如果写成5:00则会被解析为5分钟。Torque的时间格式需要特别小心HH:MM:SS格式是首选不要混淆。场景三没有设置默认队列如果不执行set server default_queuebatch提交作业时没有显式指定队列系统会报错Bad queue。我在测试过程中就碰到过一次这里提醒一下。10. systemd服务配置让Torque开机自启10.1 为四个进程分别配置服务文件既然要让Torque作为生产环境的基础服务就必须配置开机自启。最佳实践是为四个进程各写一个systemd服务文件。我在/etc/systemd/system/目录下创建了4个文件。第一个是trqauthd.service[Unit] DescriptionTORQUE Authentication Daemon Afternetwork.target [Service] Typeforking ExecStart/usr/local/torque/sbin/trqauthd ExecStop/usr/bin/killall trqauthd Restarton-failure [Install] WantedBymulti-user.target第二个是pbs_server.service[Unit] DescriptionTORQUE Server Daemon Afternetwork.target trqauthd.service [Service] Typeforking Usertorque Grouptorque ExecStart/usr/local/torque/sbin/pbs_server ExecStop/usr/local/torque/sbin/qterm -t quick Restarton-failure [Install] WantedBymulti-user.target这里需要注意我在初始化完成后pbs_server启动命令里就没加-t create参数了。第三个是pbs_sched.service[Unit] DescriptionTORQUE Scheduler Daemon Afternetwork.target pbs_server.service [Service] Typeforking Usertorque Grouptorque ExecStart/usr/local/torque/sbin/pbs_sched Restarton-failure [Install] WantedBymulti-user.target第四个是pbs_mom.service[Unit] DescriptionTORQUE MOM Daemon Afternetwork.target pbs_server.service [Service] Typeforking Usertorque Grouptorque ExecStart/usr/local/torque/sbin/pbs_mom ExecStop/usr/local/torque/sbin/pbs_mom -shutdown Restarton-failure [Install] WantedBymulti-user.target配置完成后启动所有服务并设为开机自启sudo systemctl daemon-reload sudo systemctl start trqauthd sudo systemctl start pbs_server sudo systemctl start pbs_sched sudo systemctl start pbs_mom sudo systemctl enable trqauthd pbs_server pbs_sched pbs_mom10.2 一个容易踩的坑Type类型设置上述服务文件我全部采用Typeforking方式。这是因为Torque的守护进程启动后父进程会主动守护子模式向systemd发回准备信号。如果你错误地设置为Typesimplesystemd会认为服务启动失败在After依赖关系下pbs_server启动不了会导致后续的pbs_sched和pbs_mom全部起不来。我自己第一次配置时就犯了Typesimple的错误导致pbs_sched反复重启日志里全是Connection refused。把这个参数改了之后服务链路立刻恢复。10.3 服务启动失败后的日志定位如果systemd服务启动失败第一步不是改配置而是用命令定位失败原因sudo systemctl status pbs_server sudo journalctl -u pbs_server -n 100journalctl的输出里如果出现Permission denied多半是/var/spool/torque目录下的文件属主不对。出现Cannot open config file是管理目录权限出了问题。出现Address already in use多半是默认的15001端口被占用。另外检查一下SELinux。Ubuntu默认不启用SELinux但如果你之前配置过AppArmor需要确认没有限制Torque进程的权限。我在系统上检查了AppArmor状态发现有几个策略文件对/usr/local目录下的进程有约束顺手对Torque相关进程的允许规则做了补充。11. 进阶配置计算资源与门禁策略11.1 资源限制配置运行状态稳定后我开始配置更细粒度的资源限制。在qmgr里为每个队列设定资源上限/usr/local/torque/bin/qmgr -c set queue batch resources_max.ncpus 80 /usr/local/torque/bin/qmgr -c set queue batch resources_max.walltime 72:00:00 /usr/local/torque/bin/qmgr -c set queue batch resources_default.nodes 1 /usr/local/torque/bin/qmgr -c set queue batch resources_default.ppn 1资源限额设置的主体思想是宁缺毋滥。在最后一条default ppn1这个设置上它的价值在于即使提交者没有指定ppn参数作业也至少占用一个核心。如果这个值设成0可能造成作业申请了节点却没申请核心的情况调度器会分给它零个CPU时间片作业虽然处于运行状态但永远无法继续执行。11.2 队列优先级与用户权限多用户环境下设置队列优先级几乎是刚需。qmgr里可以直接指定队列的优先级/usr/local/torque/bin/qmgr -c set queue batch priority 100Torque的qsub命令在提交时可以指定任务优先级qsub -p优先级范围-1024到1023调度器会优先调度数值高的作业。我在实际配置时通常把生产队列优先级设为100让常规作业不至于被过低的优先级拖垮。如果你需要限制某些用户的使用权限qmgr也支持类似下面的配置/usr/local/torque/bin/qmgr -c set queue batch acl_user_enable true /usr/local/torque/bin/qmgr -c set queue batch acl_user_add user1,user2注意设置acl_user_enabletrue后任何未被授权的用户提交作业时都会收到Permission denied错误这个功能开启前务必确认用户列表完整否则生产环境容易出事。12. 经验总结与备选方案12.1 这事为什么不能靠抄作业解决在我完成了整个安装过程后回头反思最深的体会是网上能搜到的Torque安装教程绝大多数是CentOS上的针对Ubuntu的少数几篇又停留在18.04时代。而Ubuntu 20.04的GCC、OpenSSL、systemd等基础组件相比早期版本发生了很大变化直接照着旧教程一步步执行踩坑几乎是必然的。我的建议是如果你想在Ubuntu 20.04上装Torque 6.1.2遇到编译错误时不要急着搜Ubuntu Torque 错 error这种组合词而是把具体的错误信息贴到GitHub Issues里搜。很多年前就有人提交过GCC 9相关的issue虽然官方不维护了但issue_list里保留了大量讨论这些信息比多数博客都更有价值。12.2 卸载与回退方案如果你在安装过程中被GCC 9编译问题折磨得狼狈不堪或者中途决定放弃Torque改用Slurm我这里也把干净的卸载流程写一下sudo systemctl stop pbs_mom pbs_sched pbs_server trqauthd sudo rm -rf /usr/local/torque sudo rm -rf /var/spool/torque sudo rm -f /etc/systemd/system/pbs_*.service sudo rm -f /etc/systemd/system/trqauthd.service sudo systemctl daemon-reload如果之前创建了torque用户也可一并清理sudo userdel -r torque这套卸载流程同样适用于安装中途遇到不可控错误时恢复到干净的初始状态重新开始。12.3 我对Torque单机版的最终评价用了一个多月跑了上千个作业之后我对Torque 6.1.2单机版的评价是它能用但你必须接受它的老派。无论是最初的编译安装还是日常运维时的命令操作逻辑它都停留在上一个十年的习惯里。但正是这种老派和稳定让很多存量科研系统至今仍然依赖它。如果你跑的计算任务并不复杂只是想给一台多核服务器加上作业队列能力Torque单机版完全可以胜任。最后分享一个运维小技巧。我习惯每天用crontab做一次Torque状态的巡检把pbsnodes和qstat输出写入日志0 8 * * * /usr/local/torque/bin/pbsnodes -a /var/log/torque_daily_report.txt 21 5 8 * * * /usr/local/torque/bin/qstat -f /var/log/torque_qstat_report.txt 21这个习惯帮我提前发现了多次由于深夜机器重启导致的节点状态异常。集群调度类的服务最怕的不是配置复杂而是你平时不看它、它一出事就直接把积累半天的作业全部卡死。定期巡检是保证这类老旧系统稳定运行最便宜也最有效的方法。