为普通用户(非root用户)提供初始化和closures自动运行function

我正在运行一个运行Debian Wheezy 7.4.0发行版的实验/testingLinux机器。 不同的用户通过sshlogin到他们的帐户,并允许运行开发工具,如果他们愿意,他们的程序作为服务在后台运行。

由于这是一个用于各种用途的testing机器,通常需要重新启动整个机器,然后用户必须重新login并重新启动正在运行的用户空间。 我想自动化。 基本上我想提供给用户一个意思是在机器启动之后(在所有其他部分被初始化之后)启动东西,并且意味着在系统closures时启动东西(没有时间限制,基本上停止closures直到所有这些closures用户进程已经完成)。

我到目前为止所尝试的:
我已经创build了一个init bash脚本,通过在/etc/init.d/(骨架模板源代码: https : //gist.github.com/ivankovacevic/9917139 )下的“骨架”模板文件中find的原则,

我的代码在这里: 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中没有其他的脚本/服务在启动之后会挂起这样的进程。

所以我正在找人帮我debugging我的解决scheme(这在我看来也有点复杂)。 或者给我一些想法,这可以以完全不同的方式来实现。

UPDATE
我已经为startpar问题启动了一个单独的问题: 从rc.local或init.d启动进程时startpar进程挂起

更新2
问题解决了我原来的解决scheme。 检查之前提到的startpar问题。 GitHub上的代码也被修正以反映这一点。

更新3 – 如何使用crontab
正如Jenny所build议的,普通用户可以使用crontab在启动时执行一次任务。 我发现这是最简单的方法,如果你只需要在启动时启动用户任务而不关机。 但是,当用户启动持续的,类似服务的任务时,用户可以离开cron进程作为父母。 首先让我解释它是如何工作的:

普通用户应该自己打电话:

 crontab -e 

(-e如在编辑中 )这将打开一个默认的控制台文本编辑器与他们的用户crontab文件。 要添加要在启动时执行的任务,用户必须在文件末尾添加一行:

 @reboot /path/to/the/executable/file 

现在,如果用户可以做到这一点,如果该文件不是一些简单的脚本,线性完成某些事情并结束,而是一些看门狗,例如,在重新启动后,您可以在您的进程列表中结束这样的事情:

  1 2661 root 20 0 20380 860 660 S 0.0 0.0 0:00.00 ├─ /usr/sbin/cron 2661 2701 root 20 0 33072 1152 868 S 0.0 0.0 0:00.00 │ └─ /USR/SBIN/CRON 2701 2944 someuser 20 0 4180 580 484 S 0.0 0.0 0:00.00 │ └─ /bin/sh -c ./watchdog 2944 2945 someuser 20 0 10752 1204 1016 S 0.0 0.0 0:00.00 │ └─ /bin/bash ./watchdog 2945 2946 someuser 20 0 23696 4460 2064 S 0.0 0.1 0:00.01 │ └─ /usr/bin/python ./some_program.py 

为了避免用户需要修改他的crontab项目如下所示:

 @reboot /path/to/the/executable/file >/dev/null 2>&1 & 

文件描述符的redirect是可选的,但build议保持干净。 如果你想研究为什么,试着看看他们:

 ls -l /proc/pid_of_started_process/fd 

我同意你的解决scheme看起来有些复杂,所以我会去“给我一些想法,这可以用一种完全不同的方式来实现”:-)

  1. 标准的解决scheme是使用configurationpipe理系统,如puppet,并允许用户添加他们的东西到服务器的puppetconfiguration。 木偶将推出开始脚本,并将其添加到相关的运行级别。

  2. 更快的方法是让他们sudoedit访问/etc/rc.d/rc.local并在那里添加他们的东西。

  3. 或者为每个目录提供他们想要启动的启动脚本,并且有一个cron作业将这些脚本复制到/etc/init.d ,在适当的位置插入su $USER -c并在其上运行chkconfig。

  4. 或者给他们一个目录来放置启动脚本,并在fo /etc/rc.d/rc.local结尾添加一些行以遍历这些目录,并在每个脚本上运行编辑的 su $USER -c 'script start'在他们中。

编辑添加: 5.让他们使用crontab安排作业运行@reboot