systemd service файл для запуска java процесса ч.7685796

Тебе нужен Type=simple. С комментария поржал: вообще-то, вся задача systemd именно в том, чтобы сообщать, если «на старте что-то пошло не так».

Но оно не справляетяс со своей задачей! Если ставлю simple, то после

systemctl start some.service

Ничего не понял из твоих слов. И, кажется, ты тоже ничего не понял :)

Ты не должен выбирать Type= исходя из своих личных соображений. Он выбирается детерминистично исходя из того, как ведёт себя запускаемая программа. Type=forking выбирается, когда программа демонизируется. Type=simple — когда не демонизируется. Всё остальное решается другими способами.

Но оно не справляетяс со своей задачей!

Что за «задача», с которой нужно справляться?

Ты не должен выбирать Type= исходя из своих личных соображений. Он выбирается детерминистично исходя из того, как ведёт себя запускаемая программа. Type=forking выбирается, когда программа демонизируется. Type=simple — когда не демонизируется. Всё остальное решается другими способами.

Это уже интереснее! Если в конце ExecStart я добавлю «&» это будет считаться за демонизацию?

Что за «задача», с которой нужно справляться?

Задача выдать при старте «failed to start some_shit, see systemctl status shit.service» если что-то пошло не так.

#если сделать type=simple, то юнит не падает с ошибкой, если на старте что-то пошло не так.

Уточняющий вопрос — если что-то пошло не так и some_shit завершился с ошибкой, то какой при этом exit code? Подозреваю, что несмотря на ошибку — нулевой, вследствие чего systemd думает, что все хорошо. Если подозрение верно, то, боюсь, придется костылить.

Если в конце ExecStart я добавлю «&» это будет считаться за демонизацию?

Нет, systemd — это не sh, и шелловые конструкции он не интерпретирует.

Задача выдать при старте «failed to start some_shit, see systemctl status shit.service» если что-то пошло не так.

Понимаешь, тут есть принципиальная проблема. systemd не знает и не может знать, в какой момент у some_shit заканчивается запуск и начинается непосредственно работа. То есть: если сервис упал через 2 миллисекунды — это он упал, потому что не смог распарсить конфиг или потому что он распарсил конфиг, запустился и успел крашнуться? А если через 500 миллисекунд? А через 5000? Сколько systemctl start должен ждать краша, прежде чем говорить «мы запустились» и возвращать управление пользователю?

Если сервис не сообщает systemd, в какой момент он закончил запускаться и начал работать — эта задача принципиально не решается.

Можно заставить ждаву выдавать правильные екзит коды? Если тряхануть програмистов? Или может, можно заставить системд воспринимать некоторый выхлоп за ексит код? В целом, я понял мыслю и кажется придётся всё-таки городить костыляку.

Нет, ты ничего не понял. Дело не в exit-кодах. Ещё раз: как systemd поймёт, когда заканчивается «старт» и начинается «работа»? В какой момент systemctl должен вернуть управление?

Вроде какой-то там таймаут есть... TimeoutStartSec?

Этот таймаут совсем о другом. TimeoutStartSec — это время, по истечении которого юнит будет прибит, если не перейдёт из фазы «старт» в фазу «работа». В случае Type=simple фаза «старт» вообще пропускается — как я уже сказал, в этом случае systemd не имеет возможности отличить одно от другого.

Так что кури systemd.service(5) до ещё больших дыр.

Спсибо, я понял немного что к чему, теперь я уверен, что вставить костыль будет быстрее.

Прежде чем разбираться с systemd, сначала разберись со своим демоном. Ответь на вопрос: как сам демон сообщает о том, что он закончил стартовать и начал работать? Если он этой информации не сообщает ­— ты ничего не сможешь сделать. И только в противном случае можно думать над тем, как передать эту информацию в systemd.

Да, я уже тряхнул програмистов и они начали неспеша обещать впилить правильные экзит-коды, через 30 лет, если повезёт... Всё-таки приложуха совсем не линукс-совместима. Правда, это типа вроде как бета, но всёравно обидно. Ещё раз спасибо.

Повторяю: exit-коды тебе никак не помогут.

По завершении нормального старта приложение плюёт в лог сообщение вида:

Listening for HTTP on /0:0:0:0:0:0:0:0:9000

if [[ -z $(systemctl status adept-backend.service | grep "Listening for HTTP") ]]; then exit 9; fi;

С этого и нужно было начинать.

Ставишь Type=forking и пишешь элементарный скрипт-обёртку, в котором:

• вешаешь обработчик на SIGCHLD, который делает wait и завершает скрипт c этим кодом возврата
• запускаешь демона через &
• запускаешь греп по журналу (journalctl -f -n0 -u <имя юнита> | grep -q <строка>)
• выходишь с нулём

В этом предложении есть небольшая гонка (между запуском демона и запуском journalctl), поэтому если в твоей версии systemd есть поддержка invocation id — лучше сделай -nall и отфильтруй по текущему invocation id.

Используй sysvinit, systemd так не умеет.

Как тока загоню его на свежайший РХЕЛ на нашем продакшене, ага

вам не exit codes нужны, а почитать про sd_notify, и научить приложение сообщать systemd свой статус при запуске при Type=notify

Ну или можно сделать скрипт запуска, который стартует сервис и затем проверяет systemctl is-failed.

делай враппер

debug-start.sh

systemctl restart my123.service && journalctl -u my123.service -f

и пиши адекватно в логи. Всё, как на ладони!

Жаль, всё как всегда нужно на вчера а я выгляжу самым незагруженным человеком на проекте, не то, что погромисты!

systemctl is-failed

Вот спасибо! Как раз про эту опцию я и забыл, очень помогла мне в моём костылестроении, а вернее сократила предыдущую конструкцию отсюда systemd service файл для запуска java процесса ч.7685796 (комментарий)