干了这么多年 SAP Basis几乎每个月都能遇到一次这种怪问题用户明明在 SAP 里点了打印SP01 里也看得到自己的 Spool Request可到了操作系统层、到了打印机队列里一查作业的属主却变成了 sidadm甚至被打印服务器管理员当成“来路不明的僵尸作业”直接清掉了。反过来也有用户问为什么有时候打印队列里能看到自己的 SAP 用户名有时候却只有 SIDADM这问题看着小其实牵扯到 SAP 打印架构里最容易搞混的两层“归属关系”。今天就把这层窗户纸捅破。这篇文章适合三类人看刚接手 SAP Basis 的运维新手被用户打印问题缠烦了的系统管理员以及做安全审计时经常被“sidadm 打印了文档”这种误报坑到的安全同学。读完你就能准确判断一个打印作业在不同层面到底属于谁也能在打印排查中少走弯路。1. 先分清打印作业的两层 OwnerTSP01 里的 SAP 用户 vs 操作系统里的 SIDADM很多人第一次接触这个概念都会被绕进去核心原因就是把两个完全不同的“属主”混在一起来看。一个打印作业在 SAP 世界里至少有两层身份搞清楚了这个问题后面所有的判断都不会错。1.1 SP01 里看到的 Owner 是 SAP 层的业务身份你打开事务码 SP01Spool Request List每个 Spool Request 都有一列叫 Owner这一列存的是创建这个打印请求的 SAP 业务用户。比如某个业务员用账号 ZHANGSAN 跑了报表并点打印那这个 Spool Request 的 Owner 大概率就是 ZHANGSAN。这个 Owner 记录在哪底层表是 TSP01Spool Request Header关键字段就有一个 OWNER。数据是 ABAP 程序在调用打印函数、执行 WRITE 到打印页面时写进去的。你可以简单理解成SP01 里的 Owner 在 SAP 业务逻辑层谁发起了这次打印。它回答的是“人在哪一层操作”的问题。这层 Owner 由 SAP 的权限体系保证是审计时的权威依据。比如某份机密报表被打印了安全部门要查“谁打的”应该以 SP01 里的 Owner 为准而不是以操作系统打印队列里的用户名为准。因为 OS 队列里的用户名很可能是统一的 sidadm。1.2 操作系统里的作业属主是执行进程的系统身份到了操作系统这一层事情就完全换了一套逻辑。当 SAP 的 Spool Work Process 把 Spool Request 转换成 Output Request并且需要真正调用外部打印命令比如 Unix/Linux 上的 lp、lpr时这个外部命令进程是谁启动的它在 OS 层记录的作业属主就是谁。这里有个绕不开的事实SAP ABAP 应用服务器的几乎所有后台进程——dispatcherdispwork、work process、包括 spool work process都是在一个叫 sidadm 的操作系统用户下启动的。sidadm 是安装 SAP 时自动创建的专用账号名字通常是 SID adm比如 PRD 系统的 sidadm 就叫 prdadm。所以当 spool work process 需要输出到物理打印机时它 fork 出来的 lp 命令天然就是 sidadm 的用户上下文。操作系统打印队列里记录的作业属主自然就是 sidadm。这一层回答的是“在 OS 层是哪个服务账号执行了打印命令”的问题。1.3 两层归属对不上是正常现象不是故障把上面两个概念放一起你会发现一个很有意思的结果一个后端打印作业SAP 里看 Owner 是 ZHANGSANOS 打印队列里看 Owner 是 sidadm。这两者同时成立互不矛盾。这不是故障也不是权限配置错了而是 SAP 打印架构的默认设计。SAP 应用层记录的是业务身份操作系统层记录的是进程运行身份。业务身份用来追溯“人的操作”系统身份用来承载“进程的资源归属”。审计、追责看前者查进程、清队列、看资源消耗看后者。搞懂了这只是角色分工你再看打印相关的问题思路就会清晰得多用户为什么在打印机上看不到自己的名字因为后端打印的作业统一挂在 sidadm 下面。用户为什么能取消打印因为 SAP 层有权限检查OS 层他根本没权限碰到那个 sidadm 作业。明白了这层往下继续拆。2. 什么情况下是 SAP 用户什么情况下变 SIDADM回到最初的疑问既然默认后端打印的 OS 属主是 sidadm那“有时候变成 SAP 用户”是怎么回事实际上这完全取决于你用哪种打印访问方法以及打印命令由谁、以什么参数发起。下面分场景说明。2.1 默认后端打印路径OS 作业几乎全是 SIDADM绝大多数 SAP 系统在 Unix/Linux 平台上的后端打印走的是访问方法 UUnix LP/LPR。SPAD → Output Devices → 选择设备 → Device Attributes 里可以看到 Access MethodU 方法对应的是 Unix 系统原生打印命令。这条路径的执行过程是spool work process 把打印数据写到临时文件然后调用类似lp -d PRINTER -t Title /usr/sap/TMP/file这样的命令。因为 spool work process 运行在 sidadm 用户下这个 lp 命令的属主就是 sidadm。实测一下很简单。你在 SAP 里随便打印一个东西然后登录应用服务器执行ps -ef | grep -E lp|lpr|lpstat | grep PRD或者查看打印队列lpstat -o -u PRDADM你能看到一堆作业的属主都是 prdadm。这不是异常这就是标准后端打印的样子。所以说如果客户打印服务器管理员质问你“你们系统怎么总是用 sidadm 打作业”你可以理直气壮告诉他所有 SAP 后端打印都是这个账号在执行这是 SAP 的标准行为。2.2 前端打印X 访问方法作业根本不在应用服务器上出身那什么时候 OS 层能看到用户自己的名字最典型的是前端打印也就是访问方法 XFrontend Printing。这种模式下SAP GUI 会弹出一个打印对话框由客户端本地操作系统来发起真正的打印作业。后端服务器做了什么工作它只负责把打印数据准备好通过 SAP GUI 通道传给客户端。真正的打印动作是用户本机的 Windows/macOS 在操作。所以你本机如果在公司域里打印机队列显示的用户名通常是你登录电脑的域账号或者显示本机用户名而不是 sidadm也不是 SAP 用户名。注意一个区分点如果用前端打印作业的 OS 属主 客户端登录用户。如果你在服务器端查打印队列可能什么作业都查不到——因为作业根本不在服务器上的打印队列里它已经跑到你本机连的那个网络打印机队列去了。很多新手在这里会绕晕以为作业丢失了其实只是换了一条出生路径。2.3 定制访问方法脚本里自己改了用户映射除了 U 和 X还有很多企业用访问方法 FExternal Print Command或 EExternal Exit自己写一段脚本去处理打印输出。这种定制脚本通常非常灵活灵活到可以“篡改”打印作业在 OS 层的属主。举个例子我见过一家企业为了在打印服务器上按部门区分作业在 F 方法脚本里接收 SAP 传过来的 spool request 参数然后从 TSP01 里查到真实 SAP 用户名把它映射成 AD 域账号最后调用lp -U mapped_username -d printer ...。这种情况下打印服务器上显示的就是映射后的 SAP 用户名而不是 sidadm。lp -U是 System V 打印系统里指定作业属主的参数。只要调用命令的进程有权限通常是 root 或 lp 管理员它就能把作业用户改成任意值。这类定制方案一旦上线OS 层作业属主就会千奇百怪可能是 SAP 用户名、映射域账号、甚至部门代码。这也是“有时候变成 SAP 用户”的另一个来源。所以以后再看到打印队列里的作业属主一会儿是 sidadm、一会儿是某个 SAP 用户名先别急着下结论先看设备用的是哪一种访问方法。访问方法决定了打印命令的调用方式调用方式决定了 OS 层属主。3. 打印链路全景拆解从 ABAP 程序到 OS 打印命令前面解释了现象这一节把完整链路串一遍。理解整条数据流之后你甚至能预判打印作业会在哪一层出现什么状态、以什么用户身份出现排查问题会非常有底气。3.1 从程序执行到 Spool Request业务层完成了“交单”当一个 ABAP 程序执行打印动作比如报表调用NEW-PAGE PRINT ON或者 ALV Grid 调用函数REUSE_ALV_LIST_DISPLAY并触发打印SAP 会生成一条 Spool Request。这个请求记录写进 TSP01Owner 就是当前 ABAP 会话的用户。不一定是直接操作用户。后台作业Background Job打印时Owner 通常是定义作业的用户或者作业运行选定的用户名RFC 调用的打印Owner 可能是调用方传入的用户。但总体来说这一层的属主是 SAP 的业务身份是“谁发起”的逻辑记录。这里数据量往往不小打印数据集会存在 TSP03 之类的后台表里。系统根据 spool 配置决定是立即输出还是放到某个时间点再输出。注意到此为止操作系统根本不知道有打印这回事一切都还在 SAP 的数据库和应用层打转。3.2 Spool Work Process 的“接单与派单”OS 层打印命令由此出生Spool Request 生成后交给 Spool Work Process 去处理。Spool Work Process 是 SAP 实例里负责假脱机服务的进程数量通常很少有的系统只配了 1 个。它把 Spool Request 转成 Output Request并决定用什么访问方法、什么设备、什么时间输出。当它决定“现在输出”并且访问方法是后端打印如 U时spool work process 就会在应用服务器的 OS 上启动一个外部命令。由于 spool work process 本身是 sidadm 用户上下文它 fork 出来的 lp、lpr、脚本等子进程OS 层自然全部归属 sidadm。你可以把这一步理解成SAP 业务层把”打印订单“交给了后厨spool work process后厨师傅sidadm亲自下厨。顾客SAP 用户点的菜但真正在灶台前忙活的是师傅。所以打印服务器看到的作业属主是师傅的名字而不是顾客的名字。3.3 临时文件与日志sidadm 还掌握着中间产物除了 lp 进程本身后端打印还会产生临时文件。打印数据从数据库读出来后往往需要先落地到一个临时文件才能让 lp 命令读取。这个临时文件一般放在 /usr/sap/tmp 或类似的系统临时目录下。这些文件的属主也是 sidadm。很多安全扫描工具会扫描文件系统发现“某个临时目录下有一堆 sidadm 属主的文件”然后报一个高风险。实际上这就是 SAP 打印正常运转的中间产物文件存在时间很短一般打印完成就会被清理。另外还有 SAP 自己的 spool 日志存在 /usr/sap/ / /log 下属主同样是 sidadm。所以你在 OS 层做打印链路排查时基本绕不开 sidadm从进程到文件、从队列到日志sidadm 才是 OS 层唯一的“权威身份”。明白了这条链路我们就能聊排查技巧了。4. 实操排障如何快速定位打印作业到底归属于谁前面全是原理这一节给真正能用的排查手段。遇到用户报“作业打了没出来”“作业出来但用户不对”“打印服务器看不到作业”之类的问题照着下面的步骤来基本五分钟内能锁定问题在哪一层。4.1 三条命令理清当前打印链路第一条命令查 SAP 层归属与状态。登录 SAP GUI进入 SP01输入用户、日期范围找到目标 Spool Request查看 Owner、Device、Status。如果状态是 Completed说明 SAP 认为已经把数据交付给 OS 层了。如果状态是 Waiting 或 Error说明问题出在 spool 生成或访问方法执行阶段先别去看 OS。第二条命令在应用服务器上查外部打印进程。进入 sidadm 的 shell 环境执行ps -ef | grep -E lp|lpr|lpstat | grep SID正常后端打印时你会看到 lp 或 lpr 命令还在跑或者刚跑完。如果这里什么命令都没有但 SAP 里状态却是 Completed那很可能访问方法是个脚本脚本内部又把任务扔到后台异步执行了需要往下查脚本逻辑。第三条命令在打印服务器上查队列作业。Unix/Linux 打印服务器上执行lpstat -o注意看作业的 Owner 列。如果是 sidadm说明作业确实是后端打印上来的如果是某个业务账号说明走了定制映射或前端打印。这一步能帮你判断用户反馈的“作业没出现”到底是没送到还是送错归属了。4.2 场景一为什么打印服务器上只看到一堆 sidadm客户打印服务器管理员最常找上门来的一句话是你们 SAP 的打印作业全部挂在 sidadm 账号下我根本分不清是哪个用户打的而且这些作业权限很统一普通用户自己根本删不掉。这个现象不是故障是默认架构。你要做的就是给管理员解释清楚SAP 应用服务器所有后台进程统一使用 sidadm 运行所以外部打印命令必然以 sidadm 身份发起。至于业务用户是谁在 SAP 的 SP01/TSP01 里才能看到。打印服务器层面如果要区分得改造访问方法比如用脚本把用户名映射到打印服务器的合法账号再通过lp -U指定。如果只是想快速给管理员一个“当前队列里哪些作业对应 SAP 里哪个 Spool Request”的查询思路可以在应用服务器上用 sidadm 配合 SAP 的 spool 一致性检查程序 RSPO1041 先拉出 spool 清单再跟 OS 队列里的时间做比对。时间点匹配往往是识别对应关系最快的办法。4.3 场景二为什么用户能在 SAP 取消作业却动不了 OS 队列用户经常在 SP01 里点了取消发现作业消失了但打印机还在吐纸。原因就在于SAP 层的取消只是把 Spool Request/Output Request 的状态改掉后端 OS 队列里的作业如果是 sidadm 提交的并不会被自动清除。要彻底清掉需要在应用服务器 OS 层以 sidadm 执行cancel job-id或者用lpstat -o -u sidadm拿到作业 ID 后再 cancel。注意这里有个坑如果打印数据已经全部发到打印机缓存里即使你在 OS 队列取消打印机也可能会把已经收到的数据打完。再遇到这种“取消不干净”的情况通常是打印机接收缓存和 OS 队列之间的延迟不是 SAP 的问题。4.4 场景三外部打印脚本擅自改了用户上下文之后定制脚本是另一个重灾区。有的顾问为了方便在 F 方法脚本里直接su - anotheruser或者通过 sudo 切换用户然后再 lp。这样打出来的作业 OS 属主既不是 sidadm也不是业务用户而是变成了 anotheruser。问题来了打印服务器的权限、配额、审计策略全部按 anotheruser 匹配几天下来各种报表和配额全乱套。排查这类问题最关键的一步是看访问方法脚本本身。SPAD → Output Devices → 选中设备 → Device Attributes → Access Method会显示外部命令的调用串。顺着脚本路径打开看注意有没有 user、su、sudo、runuser 之类的关键字有的话就解释得通了。所以我的建议是除非业务明确要求否则不要让外部打印脚本修改 OS 用户上下文。真要区分用户用lp -U映射业务账号比切换 OS 用户安全得多。切换 OS 用户会引入权限边界混乱严重时可能让打印作业以特权账号身份运行成为安全审计里的定时炸弹。5. 常见问题速查与我的踩坑笔记最后分享几个实战中高频出现的问题和处理心得都是常规文档里不会写的细节。拿个小本本记下来下次遇到可以直接抄作业。5.1 常见问题速查表现象可能原因排查方向后端打印OS 队列作业属主全是 sidadm正常架构访问方法 U 由 spool work process 以 sidadm 调用 lp无需处理按 SP01 定位业务用户打印作业在 OS 队列里看不到可能用了前端打印 X作业在客户端本机发起检查访问方法是否为 X登录客户端查本机队列OS 队列作业属主是某个 SAP 用户名使用了定制脚本做用户映射查看访问方法 F/E 脚本查lp -U参数用户在 SP01 取消作业OS 队列仍有残留SAP 取消未联动 OS cancel以 sidadm 执行 cancel 清理作业打印服务器报“user sidadm not allowed”打印服务器策略不允许该服务账号作业在打印服务器开放 sidadm 权限或改用映射脚本安全扫描报 sidadm 打印敏感文件误报实际业务用户是 SP01 里的 Owner给安全团队解释架构以 TSP01 为准审计5.2 踩坑笔记一不要轻易删打印服务器上的 sidadm 作业以前有个案例客户打印服务器管理员责任心极强看到队列里一堆 sidadm 作业以为是系统病毒或者历史残留趁夜间批量清掉了。结果第二天整个公司所有 SAP 打印全部中断——打印机实际没收到作业但 SAP 侧 spool 状态已经变成 Completed用户完全无法判断作业去哪了。这个案例告诉我们任何对 OS 打印队列的批量操作前必须先确认这些作业的发起方。而 SAP 后端打印作业的发起方必然有应用服务器来源排查时用lpstat -o -u sidadm看到的作业要和 SAP 系统时间、设备信息一一对应再决定是否清理。宁可先保留也不要凭猜测删数据。5.3 踩坑笔记二改了访问方法别忘记测试前端打印还有一次我们为了统一输出格式把一个设备的访问方法从 X 改成了 U结果所有用前端打印习惯的同事全部报“打印没反应”。原因很简单X 访问模式下 SAP GUI 会弹出本机打印对话框U 访问模式下直接走后端服务器命令用户习惯完全变了。这个改动属于典型的“只改配置、没评估体验”翻车。实操中任何打印设备访问方法的变更至少要在测试环境覆盖三类场景后端直接打印、前端打印、跨打印服务器转发。改完以后还要在 SPAD 里重新调整设备默认属性并通知用户前端对话框将不再出现。别小看这些细节打印模块一出问题全公司都在线上嗷嗷叫。5.4 踩坑笔记三排查顺序永远是从业务层到系统层遇到打印问题我个人的习惯是从上往下查绝不先从 OS 队列开始。顺序是SP01 查 Spool Request 状态和 Owner → SPAD 查设备访问方法和目标队列 → 应用服务器查 lp 进程和临时文件 → 打印服务器查队列作业。为什么这样排因为大部分打印问题根源在 SAP 层比如程序用错了输出类型、设备被停用、Spool Server 没有可用 work process这些在 OS 层完全看不出来。你先去 OS 队列折腾半天最后发现 SAP 里状态明明是 Error那就白忙活了。先看 SAP 状态能直接确定问题在不在打印链路的前半段能省很多时间。小小的体会做 SAP 打印运维最重要的是建立“分层”的思维。业务身份、进程身份、打印服务器账号这三者各管各的。只要遇到诡异问题就问自己一句我现在查的是哪一层这一层的属主应该是什么通常答案就出来了。这比背任何命令都好使。