相关疑难解决方法(0)

我正在托管一个实验/测试 Linux 机器，运行 Debian Wheezy 7.4.0 发行版。不同的用户通过 ssh 登录机器到他们的帐户，如果他们愿意，可以运行开发工具并让他们的程序作为服务在后台运行。

由于这是用于各种目的的测试机器，因此通常需要重新启动整台机器，然后用户必须重新登录并重新启动正在运行的用户空间内容。我想自动化。基本上我想为用户提供一种在机器启动后立即启动东西的方法（在其他所有东西都初始化之后）和一种在系统关闭时启动东西的方法（没有时间限制，基本上停止关闭直到所有这些关闭用户进程已完成）。

到目前为止我已经尝试过：
我已经创建了一个 init bash 脚本，遵循在 /etc/init.d/ 下的“骨架”模板文件中找到的原则（骨架模板源代码：https://gist.github. com/ivankovacevic/9917139 )

我的代码在这里：https : //github.com/ivankovacevic/userspaceServices

基本上，脚本会遍历用户主目录并在名为 .startUp、.shutDown 或 .status 的相应子目录中查找可执行文件。根据当前发生的事件，脚本会使用su执行，就好像用户自己启动了它们一样。

我目前使用这种方法面临的问题是，在系统启动并且脚本启动其他用户的所有进程后，有一个奇怪的进程挂起。这是它在进程列表中的样子：

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
root      3053     1  0  1024   620   1 17:42 ?        00:00:00 startpar -f -- userspaceServices

我不知道那个过程是什么，它的手册页没有提到 -f 参数。所以我一无所知，但我一定是做错了什么，因为没有来自 init.d 的其他脚本/服务在启动后挂起这样的进程。

所以我在找人帮我调试我拥有的这个解决方案（在我看来这似乎也有点复杂）。或者让我知道如何以完全不同的方式实现这一点。

更新
我已经针对startpar问题开始了一个单独的问题： startpar process left hanging when starts processes from rc.local 或 init.d

更新 2 …

从完整的 init.d 脚本（SysV 样式）或来自 rc.local 文件的简单单行调用启动正在进行的（类似服务的）进程时，我有一个特殊的问题，如下所示：

su someuser -c "/home/someuser/watchdog.sh &"

watchdog.sh 包含以下内容：

#!/bin/bash

cd /home/someuser

until ./eventMonitoring.py
do
    echo "Program crashed with exit code $?. Starting again..." >&2
    sleep 1
done

我总是在进程列表中留下一个额外的进程：

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
root      3048     1  0  1024   620   1 20:04 ?        00:00:00 startpar -f -- rc.local

如果我从我的 init.d 脚本启动它（来源：https : //github.com/ivankovacevic/userspaceServices）

我得到了相同的过程，但它是startpar -f -- userspaceServices

那个过程是什么鬼？为什么在查看 startpar 的手册页时没有提到-f参数？在启动时作为另一个用户启动进程方面，我做错了什么，这个奇怪的 startpar 进程也需要保留（或启动）？为什么任何其他 init.d 脚本都不存在该进程？

有人可以帮我解释一下这个问题吗？ …

使用 CentOs，我想以用户“培训”的身份运行脚本作为系统服务。我使用 daemontools 来监控进程，它需要一个以 root 身份运行并且没有 tty 标准的启动程序脚本。

下面我给出了我的五种不同尝试，但都失败了。

1. ：

   #!/bin/bash
   exec >> /var/log/training_service.log 2>&1
   setuidgid training training_command
   

   Run Code Online (Sandbox Code Playgroud)

   最后一行不够好，因为对于training_command，我们需要为trqaining 用户设置环境。

2. ：

   su - training -c 'training_command' 
   

   Run Code Online (Sandbox Code Playgroud)

   这看起来像（以不同的用户身份运行 shell 脚本）但提供 ' standard in must be tty' as su 确保 tty 存在以可能接受密码。我知道我可以通过修改 /etc/sudoers（a la https://superuser.com/questions/119376/bash-su-script-giving-an-error-standard-in-must-be-a- tty）但我不情愿并且不确定后果。

3. ：

   sudo -u training -i bash -c 'source $HOME/.bashrc; training_command'
   

   Run Code Online (Sandbox Code Playgroud)

   同一主题的变体：' sudo: sorry, you must have a tty to run sudo'

4. ：

   runuser - training -c 'training_command'  
   

   Run Code Online (Sandbox Code Playgroud)

   这个给runuser: cannot set …