Вопросы Теги

Перенос старых привычек sysvinit на systemd

При вычислении даты, до которой строки должны быть проигнорированы перед вызовом awk затем, можно сделать это:

awk -v cmpdate=20130628 '{line=$0; dateval=$8;FS="/"; $0=dateval; 
  thisdate=$3*10000+$1*100+$2; if (thisdate>cmpdate) print line; FS=" ";}' file

Редактирование 1:

Сброс FS к его исходному значению в конце. Я протестировал свой код со всего одной строкой входа так, чтобы это не имело значения...

4
02.10.2015, 21:20
2 ответа

systemd не имеет обратной совместимости с System 5 init , только System 5 rc .

Управление системой в стиле Linux System 5 состоит из двух частей: init , который выполняется как процесс №1, и rc , который отвечает за выполнение сценариев запуска и остановки. На самом деле это два разных пакета Debian. init из пакета sysvinit ; и rc обычно из пакета sysv-rc , но может быть из пакета file-rc или openrc .

/ etc / inittab - это файл конфигурации, обрабатываемый init .systemd не предоставляет для этого никакого механизма обратной совместимости. Механизм обратной совместимости System 5 с System 5 предназначен только для System 5 rc , которая запускает программы из /etc/init.d/ . (Более того, это только для этой специфической разновидности rc . Systemd не реализует механизма обратной совместимости для механизмов конфигурации file-rc и openrc.)

Это не то, что специфично для systemd. Практически нет замены init / системного менеджера (за одним исключением за три десятилетия) процессов / etc / inittab .

Чтобы подключить службу к systemd, вы должны использовать механизмы, которые она поддерживает , а именно свои собственные служебные файлы и (через генератор, который автоматически преобразует в единицы files) файлы конфигурации System 5 rc в /etc/init.d/ .

Забудьте об уровнях выполнения.

Все эти уровни запуска, с которыми вы работаете, объявлены «устаревшими» в операционных системах systemd Linux. Нет уровня выполнения 0 или 6 для входа. Их не существует без нескольких прокладок совместимости.

Чтобы служба запускалась при завершении работы, очевидный ответ, который дают многие, - создать служебную единицу, которая будет WantedBy shutdown.target . Однако здесь есть некоторые тонкие подводные камни.Лучшим, но менее очевидным ответом является создание в остальном нормального служебного модуля с DefaultDependencies = yes , чтобы гарантировать, что он конфликтует с целью завершения работы, и поместить мясо службы в ExecStop вместо ExecStart . 

[Unit]
Documentation=https://unix.stackexchange.com/questions/233561/

[Service]
Type=oneshot
User=teststand
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/home/teststand/stop_server.sh

[Install]
WantedBy=multi-user.target

Не добавляйте в сценарий оболочки своего собственного «Руководителя демонов бедняков».

Такие вещи всегда плохо пишутся.

Если ваша «служба» - это просто выполнение команды с именем «stop_server.sh», то вывод состоит в том, что это сценарий, который останавливает сервер под какой-то вручную созданной системой управления службами сценариев оболочки.

Он предназначен для этих плохо написанных, шатких, ненадежных и опасных катастроф: stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh

У вас есть systemd. Воспользуйтесь им и запустите любую службу, которая здесь запущена, используя надлежащие механизмы управления службами. Вам вообще не понадобится эта необычная служба ExecStop , если вы сделаете свою фактическую службу запускаемой через systemd с DefaultDependencies = true , как systemd будет обрабатывать завершение работы службы во время выключения.

Взять супервизора Dmon для бедняков в сценарии оболочки, который «управляет» одной службой, а затем обернуть это в служебный модуль systemd для второй службы, которую затем организуют для запуска при завершении работы, когда цель не более чем управлять первой службой и отключать ее при остановке или выключении системы - хороший способ попасть в Системный Дом Ужасов.

Мир хочет, чтобы вы очистили свой экран.

Желание не очищать виртуальный терминал между выходом из системы и последующим входом в систему очень сильно плывет против течения, как обнаружили Грег Вулледж и другие. Наличие конфиденциальных выходных данных от привилегированных пользователей или начальников, оставшихся после выхода из системы, было проблемой безопасности для Unices (и другие операционные системы с разделением времени с удаленным доступом) с 1970-х годов, и требуется много усилий, чтобы отменить все то, что люди сделали, чтобы предотвратить эту проблему.

  • Многие системы имеют стандартную команду clear_console в сценариях выхода из оболочки. (Это само по себе проблематично, поскольку она плохо работает с графическими программами, запущенными на виртуальном терминале ядра №1, и не работает с любыми другими типами терминалов, виртуальными или реальными.)

    Эта команда имеет быть удаленным.

  • По умолчанию в программах getty, нацеленных на виртуальные терминалы, таких как mingetty , терминал очищается. (Это происходит перед входом в систему, что означает, что вывод терминала может оставаться невыполненным, если служба входа в систему TTY остановлена. По иронии судьбы, эта функция была бы лучше помещена в логин , который благодаря требованиям PAM является все еще работает при выходе из системы.)

    Параметр - noclear должен быть развернут, чтобы отключить это. Это включает в себя запись одного или нескольких файлов переопределения файла модуля, изменение параметра ExecStart или просто указание autovt @ .service на локальный файл модуля, созданный пользователем.

  • systemd предоставляет getty @ .service набор служебных модулей шаблонов TTYVTDisallocate = yes , который инструктирует systemd очистить виртуальный терминал ядра. (Это опять же не работает ни с какими другими типами терминалов, даже с виртуальными терминалами пользовательского пространства, что частично отражено в его названии.)

    Это тоже нужно удалить, опять же с помощью переопределения или другого шаблона службы, на который указывает autovt @ .service .

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

11
27.01.2020, 20:46

Я работаю с CentOS 7, которая может иметь другую настройку. Однако для меня вызов getty управляется служебным файлом /usr/lib/systemd/system/getty@.service. (Символ @ служит для шаблонизации; он запускается как getty@tty1.service, а строка tty1 передается в файл и определяет, на каком TTY он запускается.) В этом файле есть строка, начинающаяся с ExecStart=, которая определяет командную строку. Здесь будут добавлены опции. (Лучше не редактировать файл под /usr напрямую, так как он может быть перезаписан при обновлении системы; сначала его следует скопировать куда-нибудь под /etc, возможно, под /etc/systemd/system, где он будет затенять файл, предоставленный производителем. )

Похоже, что то, что вы хотите получить при выключении/перезагрузке, лучше всего реализовать не путем изменения непосредственно процесса выключения/перезагрузки, а путем добавления действия в список действий по выключению службы, которые systemd будет автоматически выполнять при остановке или перезагрузке системы (или когда вы выключаете службу вручную с помощью systemctl). Быстрый способ сделать это - превратить сценарий в строку ExecStop команды системной службы; в зависимости от того, как все настроено, вы также можете создать пользовательский служебный файл, управляющий всем этим, и поместить ExecStop туда.

2
27.01.2020, 20:46

Теги

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