В течение многих лет у нас был сценарий мониторинга процесса/контроля как часть нашего приложения. Поведение скрипта по умолчанию заключается в демоннировании самого себя. Часто скрипт запускается, по необходимости, не-привилегированными пользователями. По причинам, которые я не буду излагать, нам нужно сохранить сценарий и такое поведение.Как демонировать незащищенный скрипт в OSX Yosemite 10.10.3+
На OSX систем, мы традиционно был сценарий перезагрузки себя в фоновом режиме через запуска сценария /USR/libexec/StartupItemContext, представленной Apple. Это ставит наш процесс в контексте загрузки bootstrap, а не в контексте начальной загрузки. Это необходимо, потому что без этого контекстного переключателя, если и когда пользователь выходит из системы, что также часто необходимо, скрипт теряет доступ к службам каталогов, getpwuid(), службам DNS и т. Д. Исходные внутренние строки, которые демонизировали сценарий, выглядели по существу как это (в Perl):
my $cmd = "/usr/libexec/StartupItemContext myscript @Commandline > logs/startup 2>&1" ;
system("$cmd &") ;
exit 0 ;
Когда OSX Yosemite вышел, что StartupItemContext скрипт исчез, поэтому мы перешли на прямой вызов из launchctl:
my $cmd = "/usr/launchctl bsexec/myscript @Commandline > logs/startup 2>&1" ;
system("$cmd &") ;
exit 0 ;
С недавней OSX 10.10.3 обновления, однако, bsexec субкоманду launchctl вдруг требует привилегий суперпользователя:
% launchctl bsexec
This subcommand requires root privileges: bsexec
%
Это создает для нас проблему, которая остановит всю работу непривилегированных пользователей больше не может попросите наш сценарий мониторинга/управления демонтировать себя.
Кажется, что Glassfish has encountered this problem и обратился к нему с a patch, который заменяет
/bin/launchctl bsexec/
с
nohup
Это может работать для реализации Glassfish, однако я не думаю, что для нас. Несмотря на то, что я этого не понимаю - то есть, почему простая блокировка SIGHUP помешает процессу из выведенного из эксплуатации контекста загрузочного входа в систему потерять сервисы - он также не работает в наших тестах для всех необходимых нам системных служб ,
Что новое, канонический способ демона процесса на OSX начиная от непривилегированного, Маха «вход» самозагрузка контекста, без потери доступа к критически важным системным службам, как DNS и т.д., когда пользователь выходит из системы?
Большое спасибо @Rob за информированный эскиз о том, как перестроить это. Чтобы создать свободу действий для этого, знаете ли вы какую-либо краткосрочную уловку для нашего предстоящего (недельного) срока выпуска, кроме требований, нарушающих требования _sudo_? Например, [старые технические примечания] (https://developer.apple.com/library/mac/technotes/tn2083/_index.html) предполагают, что в дополнение к контексту «входа» есть «пользовательский» сценарий начальной загрузки. Есть ли способ запустить процесс, чтобы он попадал в «пользователь» вместо контекста «входа в систему», поэтому, надеюсь, сохранился выход из системы? Мы получили ослепленные изменения Apple здесь, спасибо – lcikgl
Что TN - это карта, которую вы хотите. Я возвращаюсь к нему все время. Я верю, что вы смотрите на не-GUI LaunchAgent. Я не думаю, что они выживут. Все, что угодно «для пользователя» будет хотеть прекратить, когда пользователь уйдет. Конечно, вы можете попробовать, поставив plist в/Library/LaunchAgents. Вы можете попытаться разблокировать и отделить от своего родителя (может потребоваться двойная вилка). Возможно, это может защитить вас от выхода из системы. –