我的公司设置了一些它开发的软件，在旧版本的 SLES 上使用 init.d 作为服务运行。我们最近开始在 Amazon 的 EC2 中的 SLES 12 实例上设置新环境，并发现 SLES 12 现在使用 systemd 而不是 init.d。然而，init.d 脚本（即 /etc/init.d 中）中定义的服务似乎仍然可以正常启动，因为 systemd 在后台执行一些魔法来处理预先存在的 init.d 脚本，这很棒。
但是，我们不想以 root 用户身份运行我们的服务——而是创建一个新用户来运行我们的服务。问题是，当我们尝试以非 root 用户身份启动我们的服务时，无论 systemd 为运行旧的 init.d 服务做任何准备，都会请求 root 身份验证，我们认为这不是必要的。在较旧的 SLES 环境中（使用实际的 init.d），我们可以毫无问题地以非 root 用户身份启动服务。据我所知，我们的非 root 用户权限和文件所有权在两种环境中都是相同的。
我认为这是 systemd 对旧的 init.d 内容进行后台处理的原因是启动我们服务的脚本在启动/停止服务的实际命令之前立即回显一行文本，但该行不是't output 即我们被要求在 echo 语句之前进行 root 身份验证。隐藏在 systemd 中的某个包/模块需要身份验证，但我现在不记得它的名字了。
请注意，如果可能，我们希望避免为我们的服务创建特定于服务的 .service 文件 - 我们希望坚持使用我们拥有的 init.d 脚本，并以非 root 用户身份运行它。此外，我们希望在不使用 sudo 的情况下运行该服务（我们在旧环境中不需要 sudo）。
对于这个问题缺乏细节表示歉意 - 一旦我回到办公室并可以获取具体细节等，我会用更具体的细节更新它。但这似乎可能是一个常见问题，所以我希望有人可以对此有所了解。
具体来说：我们希望在 SLES 12 上使用 systemd 以非 root 用户身份运行使用旧 init.d …