Предоставление обычным пользователям (без полномочий root) возможности автоматического запуска инициализации и выключения

Я размещаю экспериментальный / тестирующий 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. В зависимости от текущего события сценарии выполняются с вс как будто пользователи сами их запустили.

Проблема, с которой я сейчас сталкиваюсь с этим подходом, заключается в том, что после загрузки системы остается зависший странный процесс, а сценарий запускает все процессы других пользователей. Вот как это выглядит в списке процессов:

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 зависает при запуске процессов из rc.local или init.d

ОБНОВЛЕНИЕ 2
Проблема решена для моего первоначального решения. Отметьте ранее упомянутый вопрос для startpar. Код на GitHub также исправлен, чтобы отразить это.

ОБНОВЛЕНИЕ 3 - Как использовать crontab
Как предложила Дженни, обычные пользователи могут планировать выполнение задач один раз при загрузке с помощью 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 &

Перенаправление файловых дескрипторов необязательно, но рекомендуется поддерживать их в чистоте. Если вы хотите узнать почему, попробуйте взглянуть на них:

ls -l /proc/pid_of_started_process/fd