前两天一个朋友在群里发消息说生产机的打印服务器上Spool Request的归属者Owner一会儿显示成某个业务用户一会儿又变成了sidadm问是不是哪台应用服务器配置没同步要不要把两台服务器的打印参数统一一下。我让他把 SAP 侧的SP01截图和操作系统打印队列的作业列表一起发过来看完之后我告诉他这不是配置漂移是打印链路里本来就存在两条不同的路径你看到的变化恰恰暴露了请求实际走了哪条路。这个问题看起来很偏门但做过 SAP 打印运维的人都容易撞上。因为Spool Request在操作系统层面的归属者不是由Spool Request里的创建者字段直接决定的而是由谁真正在操作系统里创建了打印进程决定的。想弄明白为什么有时是 SAP 用户、有时却变成SIDADM得先把 SAP 打印作业从发起、落库、到提交给操作系统的完整链路拆开看一遍。1. 先分清两个层面的 OwnerSAP 里的创建者操作系统里的作业归属者很多第一次排查这个问题的人会被Spool Request Owner这个叫法带偏。在 SAP 的SP01事务码里你确实能看到每个 Spool Request 都有一个创建者字段通常是发起打印的那个 ABAP 用户比如HEIZHUANG、DDIC或者某个接口账号。这个创建者记录了这个打印任务的业务归属人是谁纯粹是 SAP 应用层的信息存在数据库表TSP01里。但你在操作系统打印服务器上执行lpstat -o或打开打印队列管理界面看到的 owner是另一个概念。那是操作系统的作业归属者本质上是发起打印进程的操作系统用户名。SAP 业务账号和操作系统账号之间没有一一映射关系两个层面的 owner 对不上才是正常的对上了反而是特殊情况。这里就引出一个关键混淆点标题里说的有时是 SAP 用户有时是 SIDADM到底在哪个层面看的如果你在SAP 层面看SP01owner 永远是发起请求的 SAP 用户不会变成SIDADM。除非你把SIDADM也当成一个 ABAP 用户去登录系统发起打印但这在实际生产环境里很少见。你在操作系统层面看打印作业owner 才会在sidadm和其他用户名之间来回变。所以严格说这个问题的准确表述是Spool Request 对应的操作系统打印作业其 owner 为什么有时是应用服务器上的某个特定用户有时却是 SIDADM。搞清楚这一点排查方向就不会跑偏。顺带补一个背景SIDADM是 SAP 系统在 Unix/Linux 平台上的标准管理账号命名规则是系统标识符加adm。应用服务器的所有 work process、gateway、SAPLPD 打印守护进程默认都以这个账号运行。所以你会看到打印队列里大量作业的 owner 是sidadm这恰恰说明这些作业走了标准的外部打印链路。2. 从 Spool Request 到打印机中间其实隔了好几个进程要理解 owner 为什么变先得知道一次普通的 SAP 打印在操作系统层面到底发生了什么。我把这条链路按参与角色拆开逐个说清楚。第一步ABAP 程序生成 Spool Request开发或业务操作调用 SAP 标准的打印函数比如PRINT_TEXT、NEW_PAGE或直接写入打印程序把要打印的数据提交给应用服务器上的 spool work process。Spool work process 负责把内容写入数据库表TSP01生成一个唯一的 Spool Request 编号同时在TSP02里记录输出请求。这一步完全发生在 SAP 应用层跟操作系统没有任何关系。第二步Spool Work Process 决定由谁输出每个输出设备Output Device在后台配置里都定义了自己的输出方法。常见的有两种外部打印Host Spool和前端打印Frontend Printing。如果是外部打印spool work process 会把打印数据准备好然后交给应用服务器上的SAPLPDUnix/Linux 下进程名通常是sap/lpdWindows 下是SAPLPD.exe去处理。第三步SAPLPD 调用操作系统打印命令SAPLPD是独立于 SAP 主进程之外的辅助进程它随 SAP 实例启动运行账号就是sidadmWindows 平台上是SAPServiceSID。它拿到 SAP 传来的数据后会拼装操作系统的打印命令Unix 上一般是lp或lpr然后以自身进程的身份去调用。这时候问题就来了lp命令的进程 owner 是sidadm打印服务器上的作业 owner 自然也是sidadm。第四步打印服务器把作业交给打印机打印服务器CUPS、LPD 服务或 Windows Spooler接收到作业后在队列里登记一条记录记录的 owner 通常是提交作业时使用的用户名。如果提交方是sidadm队列里就是sidadm如果提交方是某个域用户队列里就是那个域账号。用表格把这几个阶段的参与者梳理一下会更直观阶段处理主体使用的用户标识是否影响 OS 打印作业 owner生成 Spool RequestABAP 程序 Spool Work ProcessSAP 业务账号如 HEIZHUANG否落库数据库表 TSP01/TSP02无记录 SAP 用户字段否外部打印调度SAPLPD / sap/lpdsidadm是提交打印命令lp / lpr 命令sidadm继承 SAPLPD 身份是前端打印用户本地 PC 的打印程序终端用户的系统账号是这就能解释第一个现象绝大多数标准配置下操作系统打印作业 owner 是 SIDADM是正常且符合预期的。因为打印环节真正干活的SAPLPD和它 fork 出来的lp命令只认识sidadm不认识HEIZHUANG。那有时是 SAP 用户又是怎么回事接着往下看。3. Owner 由谁创建进程决定前端打印和外部打印是两条完全不同的路操作系统的打印作业 owner 本质上遵循一个朴素的规则谁创建进程owner 就是谁。lp命令是 SAPLPD fork 出来的owner 就是 SAPLPD 的运行账号打印命令是终端用户在自己电脑上跑起来的owner 就是那个用户在打印服务器上映射的账号。所有看起来奇怪的 owner 现象都能用这条规则解释。3.1 标准外部打印SAPLPD 是唯一的手owner 必然是 SIDADMSAP 输出设备在 SPAD 里配置为Host Spool访问方式后应用服务器上的 SAPLPD 就是唯一负责递交作业的进程。这个进程以sidadm运行所以无论你在 SAP 里用什么业务账号发起打印操作系统打印服务器看到的 owner 都是sidadm。假如你在 SP01 里看到创建者是HEIZHUANG在打印服务器上看到 owner 是sidadm这不是错误而是这两层信息各说各话。3.2 前端打印打印动作发生在用户电脑上owner 变成另一个系统账号当输出设备配置成前端打印时SAP 不会把打印数据交给 SAPLPD而是把数据送到用户的 SAP GUI 客户端由用户电脑上的本地打印程序提交给打印机。如果这台打印机是网络共享打印机打印服务器上登记的作业 owner 就是用户在操作系统域里的账号比如CORP\HEIZHUANG。这是标题里有时是 SAP 用户最典型的一种来源——作业 owner 看起来跟 SAP 业务账号同名但那不是 SAP 用户是操作系统域用户。这种配置下还有个容易混淆的地方如果用户在多个终端登录、或者有人用远程桌面在服务器上操作 SAP GUI打印作业的 owner 可能变成那台机器的登录账号排查起来就像飘忽不定。3.3 外部打印命令或脚本owner 由执行命令的上下文决定还有一种情况会让 owner 变成别的名字就是输出设备配置了外部打印命令作为打印方法。有些企业为了让 SAP 打印自动加装订、拆分页、或者写入特定文件目录会在配置里写一段自定义脚本SAPLPD 会去调用这段脚本。脚本里的进程如果做了用户切换比如脚本开头写了su - root -c或者通过 sudo 执行那打印服务器上看到的 owner 就可能变成root或其他用户而不是sidadm。如果不信可以自己做个实验在 Unix 上手工执行lp命令作业 owner 就是当前登录账号用sudo -u sidadm lp提交owner 就变成sidadm。道理一模一样。用表格对比一下三种典型配置下的 owner 表现打印方式谁提交给 OS常见 owner备注标准外部打印Host Spool应用服务器上的 SAPLPDsidadm / SAPService最常见也最稳定前端打印Frontend Printing用户 PC 的本地打印进程域账号如 CORP\HEIZHUANGowner 与用户登录环境强相关外部脚本/自定义命令SAPLPD fork 出来的脚本sidadm 或脚本切换后的用户root、nobody 等需要结合脚本内容分析所以有时是 SAP 用户有时是 SIDADM的本质是同一个 SAP 系统里不同输出设备或者不同触发场景走的打印路径不一样。路径不一样操作系统层面的手就不一样owner 自然跟着变。3.4 第三方打印管理软件带来的显示层Owner这里还得补一个容易让运维人员误解的情况。很多企业上了第三方打印管理平台比如 LRS Print Manager、Printform 之类的中间件这些平台的界面上会展示每个打印作业的归属者而且显示的往往是 SAP 业务用户名。很多运维同事一看以为这就是操作系统层面的 owner。实际上这类平台通常通过 RFC 或 BAPI 从 SAP 侧获取 Spool Request 的创建者信息再绑定到自己的作业记录上。它显示的所有者是业务口径跟你用lpstat看到的操作系统作业 owner 不是一回事。如果遇到平台显示的业务用户和 OS 层 owner 对不上先别急着查 SAP 配置先确认你看的到底是哪一个层面的信息。4. 实战排查从 SP01 一路追到操作系统打印进程理解了原理之后排查这类问题就有清晰路径了。遇到owner 看起来不对劲的场景我一般按下面五步走每步都用现成工具不需要额外装任何组件。第一步确认 SAP 侧 Spool Request 的创建者和输出设备登录系统事务码SP01按用户或日期筛选出有疑问的 Spool Request双击进去看两个字段Created by创建者和Output Device输出设备。创建者告诉你这个打印任务在 SAP 业务层面是谁发起的输出设备告诉你它打算从哪个出口走出去。截图留档作为后续对比基线。第二步查看输出设备的访问方式事务码SPAD进入输出设备管理双击对应设备查看Host Spool Access Method字段。如果显示的是类似S本地打印、UUnix 打印、G图形打印这种外部打印方式那这个设备基本确定是走 SAPLPD 的如果显示的是前端打印方式那作业根本不会出现在应用服务器的打印链路里。把这一步的配置记下来判断方向就出来了。第三步定位实际处理的应用服务器在多应用服务器架构里同一个 Spool Request 不一定由用户登录的那台服务器处理。用事务码SM51查看应用服务器列表再配合SM50看哪台服务器的 spool work process 在处理这个请求。如果 SAPLPD 只装在其中某台服务器上那打印进程只会从这台服务器发起owner 也会落在这台服务器的账号体系里。第四步到操作系统打印服务器上查实际作业以 Unix/Linux 为例在打印服务器上执行lpstat -o lpstat -W not-completedlpstat -o能看到当前队列里所有作业及其 owner、job number、提交时间。如果在多个打印服务器之间做负载均衡需要挨个查一遍。同时看应用服务器上 SAPLPD 的进程和提交命令ps -ef | grep -i lpd ps -ef | grep -E lp|lpr第一条命令确认 SAPLPD 以什么账号运行第二条命令能看到实时的打印命令进程以及它的 owner。如果打印命令的 owner 是sidadm那作业在队列里显示为sidadm就有了铁证。第五步结合配置和进程信息下结论把第三步和第四步的信息拼起来输出设备配置为外部打印 SAPLPD 以sidadm运行 lp命令进程 owner 是sidadm结论就是 owner 为sidadm完全正常。如果lp命令进程 owner 是root或某个业务账号回头看输出设备配置里的自定义打印方法或外部命令脚本基本就在那里了。这套流程我走了很多次每次能快速定位到根因。最忌讳的是只看 SP01 里创建者字段就去打印服务器上对号入座那样永远对不上因为你拿苹果比橘子。5. 两个真实项目场景Owner 变化带来的管理困扰原理说再多不如看实际项目里的坑。我遇到过两个典型场景都是 owner 问题引发的事故分享出来给大家一个参考。5.1 外部脚本里悄悄切换用户业务用户看不到自己的打印任务某制造企业上线了标签打印增强逻辑为了让打印任务自动在文件名里带上物料号ABAP 侧调用了外部命令由系统管理员配置了一个自定义打印脚本。刚开始几天正常后来业务反映打印任务丢了但打印机确实有出纸。排查时发现打印脚本里有一段用sudo切换到root执行的清理动作目的是删除临时目录。问题就出在这SAPLPD fork 出脚本进程后脚本内部切换成了root之后这个进程再调用lp打印命令打印服务器上登记的 owner 就成了root。业务人员和 IT 支持用普通账号登录打印服务器lpstat -o根本看不到 root 的作业以为任务丢了。而打印机能正常出纸是因为 CUPS 后台仍然把数据送给了打印机。这个问题的根因不是 SAP 配置而是外部脚本污染了进程身份。去掉脚本里的sudo切换让lp命令始终以sidadm身份执行后owner 稳定回落业务也再没反映丢任务。5.2 前端打印导致打印管理平台账实不符另一个项目用的是第三方打印管理软件SAP 侧大部分打印机走标准外部打印但有一台测试打印机配置成了前端打印。平台管理员发现系统报表里这台打印机的作业 owner 全是各个域用户而其他打印机的 owner 全是sidadm以为是打印平台采集逻辑出错排查了平台配置很长时间。实际上打印平台没有骗人它只是如实反映了两种打印路径的差异前端打印的作业本来就不是 SAP 服务器提交的owner 是终端用户域账号外部打印的作业才是sidadm提交的。二者出现在同一张报表里看起来就像 owner 在乱跳。后来把这台测试打印机也统一改成外部打印报表口径才恢复整齐。这两个案例说明owner 问题的业务影响集中在两个地方一是权限控制二是监控对账。owner 一旦变成你预期之外的账号轻则用户看不到自己的作业、无法取消重则整个监控体系被误导误判系统故障。6. 让 Owner 稳定可控配置建议与运维要点现在回到实操层面怎么让 owner 稳定在我们想要的位置我给出几条建议按优先级排列。统一输出设备配置是首要任务如果你没有特别需求建议把所有共享打印机的访问方式统一配置为外部打印Host Spool并确保 SAPLPD 以标准服务账号运行。这样打印服务器上的 owner 就是唯一且稳定的sidadm监控、取消作业、权限管理都按一个口径来最省心。检查 SAPLPD 的启动账号在应用服务器上确认 SAPLPD 进程的启动账号。Unix/Linux 下执行ps -ef | grep -i lpd如果启动账号不是sidadm打印作业 owner 就会跟着跑偏。Windows 平台则检查SAPLPD服务对应的服务账号正常情况下应该是SAPServiceSID。这个细节容易被安装或迁移过程搞乱一旦乱了owner 的问题就会连锁出现。外部脚本不要随便切换用户凡是 SAP 打印链路里调用的外部脚本保持sidadm统一到底。如果确实需要临时切换用户做某个操作执行完lp之后切回来或者把需要特权的动作单独抽出来用其他机制处理别让打印命令本身在特权上下文里运行。这是我在第 5.1 节案例里用真金白银换来的教训。建立打印作业 owner 的巡检监控可以写一个简单的巡检脚本定时在打印服务器上抓取作业 owner 分布lpstat -o | awk {print $2} | sort | uniq -c正常情况下应该只会看到sidadm和极少数 root 系统作业。如果某天突然出现大量业务账号、nobody、或者不明用户名的作业说明有打印任务走了非标准路径需要及时排查。这套监控可以帮你把偶发 owner 异常变成主动发现配置漂移。打印管理平台的 Owner 要做映射配置如果你使用了第三方打印管理软件建议在平台侧显式配置 SAP 用户与操作系统账号的映射关系而不是依赖平台自动读取。这样平台显示的业务 owner 和 OS 层 owner 即使不一致管理员也知道两者的对应规则不会误判。最后说点个人体会。Spool Request Owner在操作系统层面忽变这件事本质上不是 SAP 出了 bug而是打印链路里存在多路径的表现。你把它当成一个诊断信号来看反而能很快摸清一台打印机的完整行为owner 是sidadm说明走的是标准外部打印owner 是域用户或特定账号说明前端打印或自定义脚本在起作用。理解了这个逻辑再碰到类似问题你连排查方向都能提前预判不用再猜来猜去。