Может системным «принять» или «унаследовать» процесс или CGroup?

Утилита join предназначена именно для такого рода задач: она объединяет два файла на основе одного из их полей, по умолчанию первого. Файлы следует отсортировать в первую очередь; поэтому

join <(sort file2) <(sort file1) | column -t

производит

Alice  Wednesday  616.556.4458
Bob    Tuesday    313.123.4567
Carol  Monday     248.344.5576
Dave   Thursday   734.838.9800
Mary   Saturday   313.449.1390
Ted    Sunday     248.496.2204

Это сортируется по имени, а не по дням недели; при необходимости вам понадобится постобработка для сортировки по дням недели ...

2
13.11.2018, 19:44
2 ответа

Нет. Процесс будет работать в другом контексте, если речь идет о systemd.

На самом деле это одна из причин, по которой следует избегать активации службы Desktop Bus. Служебные процессы, непосредственно порожденные брокером Desktop Bus, являются частью его службы, поскольку это касается systemd.

Можно перемещать процессы между контрольными группами с соответствующими привилегиями. Но это только половина дела, а другая половина, то есть убедить systemd в том, что он запустил юнит, когда этого не было, и переписать нужные части его внутренних структур данных, не предусмотрена.

Это не только не модель systemd, но и не модель большинства подсистем управления службами.

Между прочим, очень многие люди используют "отличные" сервисные подразделения для программного обеспечения Oracle, и они находятся на территории Дома Ужасов .

Дополнительная литература

3
20.08.2021, 11:09

Короче говоря, не существует способа заставить systemd считать службу запущенной, если только она не была запущена самой systemd. Одним из основных принципов systemd является согласованность в управлении службами, а наличие отдельных способов запуска службы противоречит этой идее.

Теперь в systemd есть средство для управления процессами, запускаемыми извне, что кажется несколько подходящим для описанного вами случая. На самом деле это отдельная единица измерения, прицельная единица .

Использование модуля области по-прежнему требует, чтобы ваша внешняя система взаимодействовала с systemd, поскольку модуль области действия может быть запущен только с помощью запроса шины D -к systemd, в котором передается PID, который используется в качестве начального процесса в масштаб. Кроме того, при запуске единицы области действия systemd по-прежнему хочет создать контрольные группы (, а затем переместит переданный PID в созданные контрольные группы. )Таким образом, это требует поддержки со стороны приложения, создающего новые процессы, если оно хочет, чтобы systemd управлял ими как областью действия.

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

Если проблема, которую вы пытаетесь решить, заключается в запуске службы во время загрузки, тогда:

  1. Проверьте, поддерживает ли ваш сторонний менеджер (в вашем случае Oracle NodeManager )настройку служб во время загрузки. Поскольку он управляет службой, он также должен управлять службой во время загрузки.

  2. Если вы задействуете systemd, используйте простую oneshotединицу обслуживания, которая просто запрашивает у стороннего менеджера запуск службы. Это означает обращение к стороннему менеджеру (в вашем случае, Oracle NodeManager )через какой-либо API или RPC, возможно, через HTTP, и указание ему запустить службу.

Если вы используете systemd oneshotдля запуска,затем назовите свое устройство надлежащим образом (, например, «start -foo» или «initial -foo» или «foo -startup» ), чтобы было ясно, что оно не останется «вверху», и продолжайте RemainAfterExit=какno(по умолчанию ), поэтому проверка состояния этого устройства просто скажет, что оно успешно завершено, поэтому нет путаницы в том, что это отражает состояние службы, работающей под управлением стороннего менеджера.

1
20.08.2021, 11:09

Теги

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