Re: systemd
Alexey Shrub -> debian-russian@lists.debian.org @ Thu, 12 Nov 2015 19:57:36 +0300:
AS> Думаю скрипты запуска не должны быть программами, интересно бы услышать
AS> конкретные примеры зачем это может быть нужно. Как-то же уложили всё в
AS> конфиги, значит возможно.
Это значит, что скрипт запуска просто переложили из /etc/init.d в другое
место. Или даже не переложили, а прямо его же и используют.
Конкретный пример из своей работы. Скрипт запуска веб-сервера,
выполняющего некоторую вполне конкретную задачу. Надо
1. вычистить именованные сокеты, которые могли остаться после падения в предыдущем запуске
2. поднять unicorn
3. поднять демон, выполняющий отложенные задания
База данных, фронтэнд и почтовка поднимаются отдельно, это собственно
application level. На практике пять строчек на bash.
База данных и почтовка к моменту запуска обоих демонов должны работать,
фронтэнд можно, в общем, запускать и до unicorn (идеально было бы после
того, как тот будет готов работать, о чем он вряд ли умеет сообщать, а
демонизируется, скорее всего, раньше, чем будет готов). Предъяви,
пожалуйста, конфиг для systemd.
Призовая игра. Апгрейд. Надо
1. git pull
2. если при git pull поменялся скрипт апгрейда, перезапустить скрипт апгрейда
3. bundle install
4. rake assets:precompile
5. положить вышеперечисленную пару (во время апгрейда базы она не должна пытаться работать)
6. rake db:migrate
7. только после успешного завершения поднять вышеперечисленную пару
8. обновить crontab
Особое внимание на последовательность пп. 5-7. Как провести эту
операцию с systemd, если systemd будет пытаться поднять unicorn при
обращении к сокету?
Нет, я подозреваю, что как-то можно заткнуть эту его продвинутую
функциональность на время апгрейда, потому что такое надо в каждом
втором случае. Но процедуры апгрейда, т.е. необходимости писать скрипт,
это не отменяет.
И надо заметить, что unicorn поднимается-то небыстро, так что поднимать
его по первому обращению к сокету может быть и не шибко замечательно,
лучше бы поднять пораньше, чтобы к первому обращению он уже был готов
работать.
По сравнению со всем этим идея, что мне ах, безумно не хватает
возможности начать стартовать unicorn только после того, как postgresql
готов работать (unicorn действительно нервно отнесется к отказу в
коннекте), выглядит одной из мелочей. Тупой sleep на 12 секунд в начале
скрипта запуска (только при старте системы, при апгрейде этот вариант не
выполняется) _на практике_ работает достаточно надежно, не приходится
даже изгаляться с несколькими предварительными попытками соединения
через psql. А почтовка и сама успевает запуститься раньше.
Оно, конечно, чисто в идеале было бы прям замечательно зацепиться за
зависимости (почтовка и постгрес готовы? ура, поднимаем движок), но
необходимости в _процедуре_, а не просто конфигурации, запуска это не
отменяет.
И суть, собственно, в том, что у каждой плюс-минус сложной подсистемы
эта процедура своя, поэтому единую систему конфигурации, которая бы
годилась для всех вариантов и не была бы при этом Тьюринг-полной или
близкой к тому, скорее всего, не сделать.
Тому же постгресу, если почитать его скрипт запуска, скорее всего, надо
перед стартом демона проверить базу на целостность, и если что,
попытаться починить. Это, конечно, тоже можно переписать на систему
зависимостей, но дело в том, что система зависимостей, которая справится
с любой такой задачей, неизбежно будет Тьюринг-полна. Т.е. будет
полноценным языком программирования, и скорее всего, хуже шелла, а не
лучше (ибо чтобы сделать лучше, надо и мозги иметь не хуже, чем у
отцов-основателей юникса, а такое встречается нечасто).
AS> On Чт, ноя 12, 2015 в 3:14 , Artem Chuprina <ran@lasgalen.net> wrote:
>> Потому что это не конфиг, а программа запуска. Которая неизбежно
>> является программой, потому что у многих сложных сервисов содержит ряд
>> нетривиальных действий. Она, кстати, не зависит от шелла, программу
>> запуска можно писать на любом языке.
Reply to: