Всем привет!
Возникла несколько нестандартная задачка. А именно есть два systemd-сервиса, первый - mySQL, второй - просто второй. Важно, чтобы второй сервис:
1. Грузился после запуска MySQL. Ну, это в юните элементарно прописывается, нет проблем;
2. Завершался перед остановом (то есть при рабочей еще) MySQL. Пишет он туда данные, надо, чтобы база эти данные приняла, и только потом отключилась (при перезагрузке компа, например).
В общем, с первым - вопросов нет никаких, а вот как средствами Systemd обеспечить желаемый порядок выключения сервисов? Я не смог найти ответа на этот вопрос.
Нестандартный вопрос по systemd
Завершайте ваши транзакции - commit - по выполнении, а не ждите останова системы.
Или сохраняйте настройки вашего сервиса в отдельный файл, а не в базу данных.
Не получится коммитить транзакции. Там "особая" ситуация - аварийное, по сигналу с УПСа, завершение работы. Произойти оно может в любой момент времени. Мало ли когда электричество выключат... Вот и надо "погасить" внешнее безмозглое оборудование, которое на том же бесперебойнике сидит. И отметить этот факт в базе данных. А потом и самому кильнутся. После чего должна и база остановиться. Но не раньше. Как-то так.
Там "особая" ситуация - аварийное, по сигналу с УПСа, завершение работы.
Это какая-то самодеятельность.
Дата-центр обеспечивает бесперебойное питание сервера.
Или у вас локальный сервер, подключённый к локальному UPS?
Стоит задуматься - а стоит ли овчинка выделки?
Не получится коммитить транзакции.
Может отследить окончание транзакции перед ребутом/шотдауном/остановом ещё одним сервисом?
У ValentinK нужно уточнить, может быть при записи в базу мускула какой-нибудь *.lock файл создаётся, чтобы было к чему прицепиться. Уже 100 лет бд не занимался и то в InterBase. ))
Всё же думаю, что данные пишутся некой "загогулиной", у которой должен быть pid. Эта же прога занимается обработкой критических ситуаций при отсутствии доступа к БД. Гарантий не даю, поскольку сие из разряда "костылей". Будет ли оно ждать - не проверял. Можно проверить на файле (изменить условие ExecStart) и поиграться с типом сервиса. Т.е. пока существует файл, должен висеть. После удаления должен уйти в ребут и т.д.
В юните ниже отслеживается pid некого процесса.
/etc/systemd/system/my-transaction.service
[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. Идиотизм конечно с моей стороны, но может и заработает... :)
У ValentinK нужно уточнить, может быть при записи в базу мускула какой-нибудь *.lock файл создаётся
Какие-то дикие понты. У него сервер с УПС. Он прикалывается.
А по-хорошему приложение свои настройки может хранить в своём файле настроек, можно .INI, можно в формате XML.
Какие-то дикие понты. У него сервер с УПС. Он прикалывается.
Ок. Однако он железки хочет увязать с программными делами. Отключили питание, сервак перешёл на упс, часы тикают до разряда. Поток данных идёт непрерывно и потоку неизвестно, отрубили питание или нет. Получается, что процесс полностью асинхронный, а поскольку ему нужно получить цельный вывод в базу без откатов и завершить сбор данных, потребуется ещё и саму "загогулину" прибить по факту завершения. Т.е... Выкл питания, Вкл UPS, тут нужно поймать сигнал от упса и приступить к завершению. Вот тут могут быть непонятки. :)
p.s. Подозреваю, что он пачками там что-то в базу грузит... Может гео- или метео-... Но это только догадки...
Ок. Однако он железки хочет увязать с программными делами. Отключили питание, сервак перешёл на упс, часы тикают до разряда. Поток данных идёт непрерывно и потоку неизвестно, отрубили питание или нет. Получается, что процесс полностью асинхронный, а поскольку ему нужно получить цельный вывод в базу без откатов и завершить сбор данных, потребуется ещё и саму "загогулину" прибить по факту завершения. Т.е... Выкл питания, Вкл UPS, тут нужно поймать сигнал от упса и приступить к завершению. Вот тут могут быть непонятки.
Но почему такие выкрутасы с MySQL?
Если бы это Oracle был с критическими данными?
Как это я разумею -
Есть данные, есть коммиты.
Не успел пройти коммит - данные надо вводить повторно.
Данные берутся из сети - значит, надо быть гтовым к отключению сети.
Или коммит не прошёл - клиент в клиентском приложении не получил подтверждения о завершении ввода данных.
У клиента по таймауту - извинения за неполадки и просьба повторно ввести данные чуть позже.
Что он хочет сохранять, в MySQL - вообразить трудно.
Да всё проще. Нет никаких Дата-Центров и не будет. Нет никаких Ораклов и не будет (мне этого на работе выше крыши). Есть просто дача, на ней небольшой сервачок на РазбериПай, который изображает какой-то интеллект по управлению инженерной инфраструктурой этой дачи. Ну, например, набрать ночью (по минимальному тарифу) бак воды, полить (в мое отсутствие сад утром и вечером) в зависимости от сухости почвы, проконтролировать температуру в комнатах и подогреть комнаты, днем слегка, а вечером - потеплее.
Вот и вся проблема в том, чтобы аккуратно завершить полив сада-огорода, не устроить там болото, если внезапно электричество пропадет. То есть надо поймать переход на бесперебойник и, если надо, по сигналу с бесперебойника, закрыть все сливные краны. А то выливать в грядки куб воды - весь урожай смоет. Оно надо? А краны закрываются в течение 7-10 секунд. Вот мне и надо всё аккуратно закрыть, отметить в базе что произошло и кильнуться.
Вот и вся задача. Не надо ничего придумывать. Надо только суметь продержать работающим MySQL до завершения закрытия этих кранов. Чтобы он не кильнулся раньше. И всего делов...
=================
В принципе - задачу можно решить и из NUT'а. Закрыть краны оттуда, а затем выключить сервер. Я хотел сделать это на чистом systemd. Но, похоже, что есть сложности.
Но почему такие выкрутасы с MySQL?
)) Это ещё не все выкрутасы... )) Предположим злой электрик взял и отрубил рубильник. Сервис принял сигнал от упса, дескать пора прекращать всё это безобразие с обработкой данных, отправил в базу последний пакет данных и прибил программу сбора. Электрик почесался и включает рубильник назад, электричество подано, упс опять перешёл в нормальный режим. Т.е. сервис сбора лёг, а питание восстановилось... Опять неувязочка... :)
Cruiser78
Тебе чего пожелать - успеха или удачи?
Есть просто дача, на ней небольшой сервачок на РазбериПай, который изображает какой-то интеллект по управлению инженерной инфраструктурой этой дачи. Ну, например, набрать ночью (по минимальному тарифу) бак воды, полить (в мое отсутствие сад утром и вечером) в зависимости от сухости почвы, проконтролировать температуру в комнатах и подогреть комнаты, днем слегка, а вечером - потеплее.
Генератор дизельный прилепить, Wilson. И мессагу на смс: "через 5 часов опускаются бронированные шторы и запускается таймер самоликвидации". :D Смех-смехом, но вещь чувствую интересная, что-то вроде "Умного дома" на Linux? А каким образом данные собираете с датчиков? Помнится на одной нефтебазе в молодости я софт-контроллер слепил, который одновременно обслуживал 10 станций налива цистерн с бензином. Вроде на одной КР580ВВ55А + мультиплексор (К155КП1 кажется) + оптопары ну и собирал данные самописной прогой (отдельный поток) в Дельфях через LPT (ECP, двунаправленный) порт, всего 20 датчиков было... Верхий уровень + импульсы литража поканально 10 штук. Всё это аккуратно складывалось в табличку DBase. Сервак держать для таких вещей, как-то, мягко говоря, слишком жирно было. А так - раз в месяц новая таблица и всё т.с. Табличка не грузится - реиндекс и вперёд. Софт то Вы сами наверное пишите под железное окружение (датчики, исп/мех)? И почему, скажем, не ПЛК? У Овнов вроде есть и готовые решения (прошивки) всяких там реле времени, измерители температуры, архиваторы с памятью и т.д. Сам я в них не спец, но в эмуляторе пробовал ваять на ST. Каким образом вы собираете данные? Просто интересно, у меня то же дача есть... Если всё это на Линуксе замутить, без ПЛК - это же определённо шаг к массовому внедрежу, т.е. шаг вперёд, однозначно.