Наша служба System V запускает демон, который запускает команду импорта. Запуск нашего сервиса с помощью sudo service myservice start запускает сервис, но когда дело доходит до создания снимка экрана, импорт не работает. Единственный способ получить скриншот - запустить сервис с помощью /etc/init.d/myservice start. После этого мы можем сделать снимок экрана командой import.
Есть идеи?
Нет прямого ответа на ваш вопрос, кроме "это зависит от среды", то есть дистрибутива GNU / Linux.
Прежде чем углубляться в полуосущественные подробности, вы должны знать, что причина, по которой sudo service import-image-service не работает, заключается в том, что команда import не имеет достаточно информации о среде, чтобы знать, где и как сделать снимок экрана. Читающий человек Судо раскрывает:
DESCRIPTION
sudo allows a permitted user to execute a command as the superuser or
another user, as specified by the security policy.
Это несколько загадочно, и узнавать об этой "политике безопасности" весело, но, возможно, это не одно из ваших любимых занятий. Я даю вам слово, что это означает, что команды, начинающиеся с sudo, запускаются в изолированной среде.
Напротив, /etc/init.d/myservice работает, потому что environment-setup-policy предпринимает шаги для настройки некоторых нормальных значений по умолчанию, таких как export DISPLAY=:0.0 . Вам придется изучить тонкости используемого дистрибутива, чтобы выяснить, как правильно информировать службу о наличии X-сервера. А пока можно попробовать sudo -E service myservice
-E The -E (preserve environment) option indicates to the secu‐
rity policy that the user wishes to preserve their existing
environment variables. The security policy may return an
error if the -E option is specified and the user does not
have permission to preserve the environment.
предупреждение: этот раздел является полу-фактическим и исторически предвзятым
Службы в системе GNU / Linux ведут себя несколько произвольно от одного распределения к другому. Главным образом, разница заключается в настройке среды до запуска службы. Это зависит от нескольких факторов, наиболее важными из которых являются:
Debian, Slackware и Gentoo (OpenRC) используют, по-видимому, аналогичный подход, в котором /etc/init.d/ services являются независимыми сценариями, которые дополнительно получают дополнительную информацию из / etc / default / servicename, /etc/conf.d/servicename и аналогичных. Сценарии могут полагаться или не полагаться на специфичные для распределения функции инициализации, такие как / lib / lsb / init-functions или /lib64/rc/sh/functions.sh. Эти дополнительные библиотеки оболочки могут получать информацию (настраивать среду) из дополнительных источников, относящихся к распространению.
Ubuntu (Upstart) и systemd используют "совершенно" разные подходы, в которых у каждого сервиса есть файл конфигурации, а система init делает всю магию.
Чтобы полностью понять, что происходит, нужно прочитать и понять систему инициализации и особенности используемого дистрибутива.
* процесс инициализации переменных среды и запуска службы.
Это очень четко объяснено на странице руководства для старой service Linux System V в самом первом предложении:
Служба запускает сценарий инициализации System V в максимально предсказуемой среде, удаляя большинство переменных среды с текущим рабочим каталогом, установленным в /.
Как вы думаете, команда image знает, где найти ваш X-сервер? Конечно, это переменная окружения DISPLAY .
Не полагайтесь на идею, что сервисы работают в интерактивной среде входа в систему с управляющими терминалами, переменными среды DISPLAY и т.д. Они не. Если вы разработали сервис, основанный на этих предположениях, то вы разработали его неправильно, и вы разработали что-то, что даже не работает для вас сейчас, не говоря уже о том, что будет работать, если вы используете другую систему инициализации, такую как systemd, upstart, nosh, runit и т. д., которые гарантируют, что на сервисы не влияют произвольные значения переменных среды интерактивной оболочки (и другого состояния процесса), когда сервис запускается / выключается.