LinuxForum.Fans
Тема

Нестандартный вопрос по systemd

Автор: Cruiser78 12 сообщений 1236 просмотров
27.09.2020 16:36 #435325

Всем привет!

Возникла несколько нестандартная задачка. А именно есть два systemd-сервиса, первый - mySQL, второй - просто второй. Важно, чтобы второй сервис:
1. Грузился после запуска MySQL. Ну, это в юните элементарно прописывается, нет проблем;
2. Завершался перед остановом (то есть при рабочей еще) MySQL. Пишет он туда данные, надо, чтобы база эти данные приняла, и только потом отключилась (при перезагрузке компа, например).
В общем, с первым - вопросов нет никаких, а вот как средствами Systemd обеспечить желаемый порядок выключения сервисов? Я не смог найти ответа на этот вопрос.

27.09.2020 17:42 · отредактировано #435326

Завершайте ваши транзакции - commit - по выполнении, а не ждите останова системы.
Или сохраняйте настройки вашего сервиса в отдельный файл, а не в базу данных.

27.09.2020 18:23 #435327

Не получится коммитить транзакции. Там "особая" ситуация - аварийное, по сигналу с УПСа, завершение работы. Произойти оно может в любой момент времени. Мало ли когда электричество выключат... Вот и надо "погасить" внешнее безмозглое оборудование, которое на том же бесперебойнике сидит. И отметить этот факт в базе данных. А потом и самому кильнутся. После чего должна и база остановиться. Но не раньше. Как-то так.

27.09.2020 18:49 #435328
"Cruiser78" написал:
Там "особая" ситуация - аварийное, по сигналу с УПСа, завершение работы.

Это какая-то самодеятельность.
Дата-центр обеспечивает бесперебойное питание сервера.
Или у вас локальный сервер, подключённый к локальному UPS?
Стоит задуматься - а стоит ли овчинка выделки?

27.09.2020 18:50 · отредактировано #435329
"Cruiser78" написал:
Не получится коммитить транзакции.

Может отследить окончание транзакции перед ребутом/шотдауном/остановом ещё одним сервисом?

У ValentinK нужно уточнить, может быть при записи в базу мускула какой-нибудь *.lock файл создаётся, чтобы было к чему прицепиться. Уже 100 лет бд не занимался и то в InterBase. ))

Всё же думаю, что данные пишутся некой "загогулиной", у которой должен быть pid. Эта же прога занимается обработкой критических ситуаций при отсутствии доступа к БД. Гарантий не даю, поскольку сие из разряда "костылей". Будет ли оно ждать - не проверял. Можно проверить на файле (изменить условие ExecStart) и поиграться с типом сервиса. Т.е. пока существует файл, должен висеть. После удаления должен уйти в ребут и т.д.

В юните ниже отслеживается pid некого процесса.

/etc/systemd/system/my-transaction.service

text

[Unit]
Description=Control end of MySQL transaction
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target

[Service] Type=oneshot или simple или forking ExecStart=/bin/bash -c 'while [[ -n $(pidof my_process) ]]; do echo "transaction active"; sleep 3; done' (в скрипт)

[Install] WantedBy=halt.target reboot.target shutdown.target

p.s. Идиотизм конечно с моей стороны, но может и заработает... :)

27.09.2020 19:08 · отредактировано #435330
"alex_q_2000" написал:
У ValentinK нужно уточнить, может быть при записи в базу мускула какой-нибудь *.lock файл создаётся

Какие-то дикие понты. У него сервер с УПС. Он прикалывается.
А по-хорошему приложение свои настройки может хранить в своём файле настроек, можно .INI, можно в формате XML.

27.09.2020 19:25 · отредактировано #435331
"ValentinK" написал:
Какие-то дикие понты. У него сервер с УПС. Он прикалывается.

Ок. Однако он железки хочет увязать с программными делами. Отключили питание, сервак перешёл на упс, часы тикают до разряда. Поток данных идёт непрерывно и потоку неизвестно, отрубили питание или нет. Получается, что процесс полностью асинхронный, а поскольку ему нужно получить цельный вывод в базу без откатов и завершить сбор данных, потребуется ещё и саму "загогулину" прибить по факту завершения. Т.е... Выкл питания, Вкл UPS, тут нужно поймать сигнал от упса и приступить к завершению. Вот тут могут быть непонятки. :)

p.s. Подозреваю, что он пачками там что-то в базу грузит... Может гео- или метео-... Но это только догадки...

27.09.2020 19:43 · отредактировано #435332
"alex_q_2000" написал:
Ок. Однако он железки хочет увязать с программными делами. Отключили питание, сервак перешёл на упс, часы тикают до разряда. Поток данных идёт непрерывно и потоку неизвестно, отрубили питание или нет. Получается, что процесс полностью асинхронный, а поскольку ему нужно получить цельный вывод в базу без откатов и завершить сбор данных, потребуется ещё и саму "загогулину" прибить по факту завершения. Т.е... Выкл питания, Вкл UPS, тут нужно поймать сигнал от упса и приступить к завершению. Вот тут могут быть непонятки.

Но почему такие выкрутасы с MySQL?
Если бы это Oracle был с критическими данными?

Как это я разумею -
Есть данные, есть коммиты.
Не успел пройти коммит - данные надо вводить повторно.
Данные берутся из сети - значит, надо быть гтовым к отключению сети.
Или коммит не прошёл - клиент в клиентском приложении не получил подтверждения о завершении ввода данных.
У клиента по таймауту - извинения за неполадки и просьба повторно ввести данные чуть позже.

Что он хочет сохранять, в MySQL - вообразить трудно.

27.09.2020 19:54 · отредактировано #435333

Да всё проще. Нет никаких Дата-Центров и не будет. Нет никаких Ораклов и не будет (мне этого на работе выше крыши). Есть просто дача, на ней небольшой сервачок на РазбериПай, который изображает какой-то интеллект по управлению инженерной инфраструктурой этой дачи. Ну, например, набрать ночью (по минимальному тарифу) бак воды, полить (в мое отсутствие сад утром и вечером) в зависимости от сухости почвы, проконтролировать температуру в комнатах и подогреть комнаты, днем слегка, а вечером - потеплее.
Вот и вся проблема в том, чтобы аккуратно завершить полив сада-огорода, не устроить там болото, если внезапно электричество пропадет. То есть надо поймать переход на бесперебойник и, если надо, по сигналу с бесперебойника, закрыть все сливные краны. А то выливать в грядки куб воды - весь урожай смоет. Оно надо? А краны закрываются в течение 7-10 секунд. Вот мне и надо всё аккуратно закрыть, отметить в базе что произошло и кильнуться.
Вот и вся задача. Не надо ничего придумывать. Надо только суметь продержать работающим MySQL до завершения закрытия этих кранов. Чтобы он не кильнулся раньше. И всего делов...
=================
В принципе - задачу можно решить и из NUT'а. Закрыть краны оттуда, а затем выключить сервер. Я хотел сделать это на чистом systemd. Но, похоже, что есть сложности.

27.09.2020 20:00 · отредактировано #435334
"ValentinK" написал:
Но почему такие выкрутасы с MySQL?

)) Это ещё не все выкрутасы... )) Предположим злой электрик взял и отрубил рубильник. Сервис принял сигнал от упса, дескать пора прекращать всё это безобразие с обработкой данных, отправил в базу последний пакет данных и прибил программу сбора. Электрик почесался и включает рубильник назад, электричество подано, упс опять перешёл в нормальный режим. Т.е. сервис сбора лёг, а питание восстановилось... Опять неувязочка... :)

27.09.2020 20:01 · отредактировано #435335

Cruiser78

Тебе чего пожелать - успеха или удачи?

28.09.2020 11:39 · отредактировано #435342
"Cruiser78" написал:
Есть просто дача, на ней небольшой сервачок на РазбериПай, который изображает какой-то интеллект по управлению инженерной инфраструктурой этой дачи. Ну, например, набрать ночью (по минимальному тарифу) бак воды, полить (в мое отсутствие сад утром и вечером) в зависимости от сухости почвы, проконтролировать температуру в комнатах и подогреть комнаты, днем слегка, а вечером - потеплее.

Генератор дизельный прилепить, Wilson. И мессагу на смс: "через 5 часов опускаются бронированные шторы и запускается таймер самоликвидации". :D Смех-смехом, но вещь чувствую интересная, что-то вроде "Умного дома" на Linux? А каким образом данные собираете с датчиков? Помнится на одной нефтебазе в молодости я софт-контроллер слепил, который одновременно обслуживал 10 станций налива цистерн с бензином. Вроде на одной КР580ВВ55А + мультиплексор (К155КП1 кажется) + оптопары ну и собирал данные самописной прогой (отдельный поток) в Дельфях через LPT (ECP, двунаправленный) порт, всего 20 датчиков было... Верхий уровень + импульсы литража поканально 10 штук. Всё это аккуратно складывалось в табличку DBase. Сервак держать для таких вещей, как-то, мягко говоря, слишком жирно было. А так - раз в месяц новая таблица и всё т.с. Табличка не грузится - реиндекс и вперёд. Софт то Вы сами наверное пишите под железное окружение (датчики, исп/мех)? И почему, скажем, не ПЛК? У Овнов вроде есть и готовые решения (прошивки) всяких там реле времени, измерители температуры, архиваторы с памятью и т.д. Сам я в них не спец, но в эмуляторе пробовал ваять на ST. Каким образом вы собираете данные? Просто интересно, у меня то же дача есть... Если всё это на Линуксе замутить, без ПЛК - это же определённо шаг к массовому внедрежу, т.е. шаг вперёд, однозначно.

Войдите или зарегистрируйтесь, чтобы ответить.