2

У меня есть скрипт на Ruby, который запускается довольно долго (в большинстве случаев 5-20 секунд), и его целью является создание файлов конфигурации для Conky и Fluxbox.

На данный момент у меня настроен сценарий Ruby для запуска во время запуска Fluxbox путем добавления его в файл ~/.fluxbox/startup , но это вызывает задержку запуска Fluxbox, так как файлы конфигурации должны быть записаны прежде, чем я смогу разрешить Fluxbox Начните.

Я обычно использую свой ноутбук, чтобы войти в терминальную оболочку (bash) только с запуском startx чтобы получить графическое окружение, когда мне это нужно. При этом я искал способ запуска сценария при входе в фоновом режиме, но только один раз. Это означает, что для любых дальнейших созданных оболочек не будет запускаться мой сценарий. Кроме того, мне нужно, чтобы это запускалось только для определенного пользователя, когда он входит в систему.

Какие у меня варианты? Мой сценарий позволяет редактировать файлы конфигурации определенных пользователей, поэтому я, вероятно, каким-то образом могу запустить мой сценарий при загрузке через пользователя root (например: сценарий инициализации установлен на уровне выполнения по умолчанию ... Если я смогу заставить Ruby работать с init без остановки последовательности init, как это делает fluxbox, или, может быть, rc.local?). Иначе есть ли способ заставить скрипт запускаться один раз, только при первоначальном входе в систему для конкретного пользователя?

Любая помощь будет оценена.

2 ответа2

2

Похоже, что он должен работать, когда ваша система достигает уровня запуска 3. Попробуйте переместить ваш скрипт в /etc/rc3.d/S50scriptname

1

Моя общая идея:

Запустите скрипт из .bashrc в фоновом режиме:

/foo/bar/script &

или, может быть, лучшая альтернатива:

nohup /foo/bar/script &

Сценарий должен проверять, был ли запущен другой экземпляр, и в этом случае он должен молча завершаться. Я не знаю Ruby, но это должно быть возможно (в случае, если это не так: создайте скрипт "wrapper" в Bash, который выполняет проверку и запускает ваш скрипт Ruby или нет). Обычными способами могут быть: ps -подобный запрос или блокировка файла dir (см. Это) в /dev/shm или /run/shm (/dev/shm находится в памяти и будет очищена при следующем перезапуске - идеально). В противном случае скрипт должен:

  • (ps -подобный метод запроса) выполняет свою работу и никогда не завершается (недорогой бесконечный цикл ожидания какого-то рода?);
  • (метод lock dir) создать блокировку dir, выполнить свою работу и выйти.

Таким образом, он будет работать только один раз.

Если вы выбираете ps подобный метод запроса, имейте в виду, что ваш скрипт будет убит при выходе из системы, если вы не используете nohup .

Редактировать:

В обычной многопользовательской среде некоторый пользователь A ружья может заблокировать сценарий пользователя B, создав каталог блокировки. Вы можете создать каталог блокировки внутри ~/ чтобы избежать этого сценария, но тогда вы должны удалить его в нужное время. Решение ps не должно быть склонным к этой проблеме.


Решение с /etc/rc3.d (ответ Гленна Джекмана) может быть хорошим. Его преимущество: он будет запускаться один раз из коробки. Между этими двумя решениями есть различия, и вы должны знать об этом (не все из них будут иметь отношение к вам в частности, но в общем случае):

  1. .bashrc запускается от имени определенного пользователя (обычно: не root); Скрипты под rc3.d будут работать как root, что потенциально более опасно в случае неудачи.
  2. Вам не нужен root-доступ для реализации решения .bashrc (хотя это может понадобиться вашему скрипту).
  3. Несколько пользователей могут внедрять решения .bashrc и это не приведет к перегрузке вашей системы, если они не войдут одновременно.
  4. На мой взгляд, это правильная реализация пользовательских решений на уровне пользователя (.bashrc), а не на уровне системы (rc3.d).

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .