systemctl (Fedora 17) и консоли взаимодействующих порожденных процессов

693
Sean

Вступление

Я недавно обновился до Fedora 17 и привыкаю к ​​новому systemctlдиспетчеру демонов по сравнению со сценариями инициализации оболочки.

Функцией, которая мне нужна для некоторых моих демонов, является возможность взаимодействия с их консолями, потому что нечистое завершение работы, не инициированное самим процессом, может привести к повреждению базы данных. Таким образом, выполнение, systemctl stop service-name.serviceнапример, может привести к необратимой потере данных.

Эти консоли читают пользовательский ввод через stdin или аналогичные методы, так что я делал на своей старой ОС то, что эти демоны были зарезервированы в screenсеансе, и я приостановил этот сеанс экрана ^A ^z. Стоит также отметить, что я теперь сделал systemctlэто автоматически, если компьютер перезагружается, но это все еще не решает мою потенциальную проблему повреждения данных, которую я пытаюсь избежать.

Мой вопрос

Есть ли способ использовать его systemctlдля непосредственного взаимодействия с консолью процессов, которые он порождает? Могу ли я подключить процесс, systemctlчтобы получить доступ к его консоли?

Спасибо

Вы, ребята, всегда даете отличные ответы, поэтому я обращаюсь к вам!

2
В общем, сценарии инициализации не должны быть интерактивными. Лучшим подходом было бы сделать так, чтобы `systemctl stop 'посылал сигнал демону, приказывая ему полностью отключиться. mattdm 11 лет назад 0

1 ответ на вопрос

1
0x90

Похоже, вы сможете перенаправить его на tty.

StandardInput = tty-force аналогичен tty, но исполняемый процесс принудительно и немедленно выполняет процесс управления терминалом, потенциально удаляя предыдущие процессы управления из терминала. tty-fail аналогичен tty, но если у терминала уже есть управляющий процесс, запуск исполняемого процесса завершается неудачно. Параметр сокета действителен только в сервисах, активированных сокетом, и только в том случае, если в файле конфигурации сокета (подробности см. В systemd.socket (5)) указан только один сокет. Если эта опция установлена, стандартный вход будет подключен к сокету, из которого была активирована служба, что в первую очередь полезно для совместимости с демонами, предназначенными для использования с традиционным демоном inetd (8). Этот параметр по умолчанию равен нулю.

Управляет, где дескриптор файла 0 (STDIN) выполненных процессов связан с. Принимает одно из следующих значений: null, tty, tty-force, tty-fail или socket. Если выбрано значение null, стандартный вход будет подключен к / dev / null, т.е. все попытки чтения процесса приведут к немедленному EOF. Если выбран tty, стандартный вход подключается к TTY (как сконфигурировано с помощью TTYPath =, см. Ниже), и выполненный процесс становится процессом управления терминалом. Если терминалом уже управляет другой процесс, исполняемый процесс ожидает, пока текущий процесс управления не освободит терминал.

Ссылка на цитату

О, и если это не сработает, мы сделаем что-то действительно сложное с сокетами Unix, которое, я уверен, вам понравится .

Винт эту ерунду, попробуйте что-то вроде этого, если вышеупомянутое не приемлемо:

Вы можете попробовать записать в каталог / proc pid. Скажите, что pid вашего демона 2000, попробуйте написать в / proc / 2000 / fd / 0

источник

Вы можете добавить эту строку в ExecStop =, что освобождает вас от необходимости взаимодействовать вручную вообще.

Я думаю, что это очень умный обходной путь для моей проблемы. Sean 11 лет назад 1

Похожие вопросы