Oracle 19c RAC 中 srvctl 报权限不足实为 systemd DefaultTasksMax 限制导致 fork 失败，典型错误是 Ora-27300 Fork Failed With Status 11；需将 /etc/systemd/system.conf 中 DefaultTasksMax 设为 infinity 并重启 OS 才能解决。
srvctl 在 oracle 19c rac 中报权限不足，通常不是 grid 用户缺 sudo 权限，而是 systemd 的 defaulttasksmax 限制导致 fork 失败——错误日志里出现 ora-27300 os system dependent operation fork failed with status 11 就是典型信号。
DefaultTasksMax=infinity 是关键修复点
Oracle RAC 启动实例时会派生大量进程（如 ora<em>lms1</em>、ora<em>ckpt</em> 等），而现代 Linux（SLES 12 SP2+、RHEL 7.4+、Oracle Linux 7u4+）默认用 systemd 限制单个服务能创建的任务数。DefaultTasksMax 默认值为 512，远低于 RAC 实际所需（常需 ≥65536）。
- 查当前值：
systemctl show --property DefaultTasksMax - 修改配置：
vi /etc/systemd/system.conf，取消注释并设为：DefaultTasksMax=infinity - 必须重启操作系统生效，仅 reload 或 restart systemd 不够
- 修改后验证：
systemctl show --property DefaultTasksMax应返回infinity
不改这个，即使 grid 用户有全量 sudo 权限，srvctl start database 仍会在后台 fork 阶段静默失败，crs 日志只显示 StartResource error for ... error code = 1。
srvctl 执行时提示 libpthread.so.0: cannot open shared object file
这是另一个常见但无关权限的误导性报错，本质是 $ORACLE_HOME/jdk/jre/bin/java 找不到系统级 C 库。
- 检查缺失库：
ldd $ORACLE_HOME/jdk/jre/bin/java | grep "not found" - 常见原因：安装时未完整部署 JDK，或
ORACLE_HOME路径下jdk目录被手动删减过 - 修复方式：重装对应版本的 Oracle Database Software（不要只拷
jdk子目录），或从同版本介质中提取完整jdk替换
该问题和用户权限、sudo、DefaultTasksMax 都无直接关系，但容易让人误判为“权限不足”。
为什么给 grid 用户加 sudo 不解决问题
-
srvctl本身不依赖 sudo 运行；它由 CRS 进程以grid用户身份调用，全程在systemd的 cgroup 约束下执行 - 即使
grid用户能sudo su -，也不能绕过DefaultTasksMax对其所属 service（如ora.crsd.service）的硬限制 - 错误地给
grid用户加ALL=(ALL) NOPASSWD: ALL反而增加安全风险，且对fork()失败完全无效
真正要调整的是系统级资源策略，不是用户权限表。
DefaultTasksMax 这个参数极容易被忽略——它不出现在 Oracle 文档的“RAC 安装检查清单”里，也不在 cluvfy 报告中体现，但却是 19c RAC 在新内核上启动失败的最高频根因。
