从你碰到的错误sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted和sudo: unable to initialize policy plugin来看，大概率是sudoers配置或环境权限层面出了问题，以下是你可能遗漏的几个核心检查方向：

• sudoers文件的语法错误
  很多人编辑sudoers后会忽略语法校验，哪怕是一个括号不匹配、权限格式写错这类小问题，都会直接导致sudo策略加载失败。你可以立刻用visudo -c命令检查sudoers文件的语法合法性，它会精准定位到错误行。如果存在语法问题，sudo根本无法正常初始化插件，自然不会在journalctl里留下执行记录。

• 目标脚本的权限与特殊属性
  你有没有检查过目标脚本的权限和文件属性？如果脚本被设置了nosuid属性（可以用stat <你的脚本路径>查看文件属性字段），sudo在切换用户执行时会无法完成权限提升，直接触发setresuid失败。另外，脚本所在的父目录权限也不能太宽松——如果其他用户对父目录有写权限，sudo的安全策略会直接拒绝执行这类存在风险的脚本，这种情况通常也不会留下日志记录。

• 系统安全模块的拦截
  不少Linux发行版默认启用了SELinux或AppArmor这类安全模块，它们可能会静默拦截sudo的权限提升操作。你可以临时关闭SELinux测试（执行sudo setenforce 0，注意这只是临时排查手段，不要长期保持关闭状态），或者用aa-status查看AppArmor的运行状态，检查是否有针对sudo或目标脚本的限制规则。这类安全拦截通常不会出现在普通的journalctl日志里，需要查看专属日志，比如SELinux的/var/log/audit/audit.log。

• sudoers配置的优先级与加载规则
  如果你是在/etc/sudoers.d/目录下的子配置文件里添加的规则，要注意这些子文件的命名不能包含.或者~，否则sudo会直接忽略它们。另外，主sudoers文件/etc/sudoers里必须有#includedir /etc/sudoers.d这一行且未被注释，否则子配置文件的规则完全不会生效。

• 用户环境变量的干扰
  有时候用户自定义的环境变量（比如篡改后的PATH、异常的SUDO_*系列变量）会干扰sudo的正常执行。你可以尝试用绝对路径执行目标脚本，或者用sudo -i切换到root完整环境后再执行脚本，看看是否还会报错。另外，检查用户的~/.bashrc或~/.profile文件，确认有没有修改过sudo相关的环境变量。

最后再提醒一句：修改sudoers一定要用visudo命令，而不是直接用vim等编辑器打开——visudo会自动在保存前做语法校验，避免你因为错误配置导致sudo完全失效，连修复的机会都没有。

内容的提问来源于stack exchange，提问作者OrcMan