такой скрипт:
#!/bin/bash
# help функции ...
mem="-J-Xms$(getServerMemory)M -J-Xmx$(getServerMemory)M"
param=$(make_params)
bin/app $mem $param .... &> console.log & // java
Выглядит ужасно, но творчество досталось в наследство. Основной вопрос вот в чем, так как эта штука запускается по разноиу и через ssh и еще написан скрипт, который проверяет жив ли процесс (самодельный systemd из фикалий и кастомных bash скриптов), может ли ОС без вмешательства пользователя такие процессы убивать? Недавно обратил внимание на логи, за день может по 2-3 раза убивать такой процесс. Условно на сервер не заходили, ничего не делали, работают только эти процессы может штук 5, и они часто падают. В логах kern.log отсуствует out of memroy и в целом по мониторингу все норм. цпу выше 30% не поднималось, памяти воз и телега.
Так же исключаю проблемы с самим приложением, там однозначно были бы логи ошибок, их нет, локально все нормально работает несколько суток.
Возможно переход на нормальный systemd должен решить эти проблемы, но хотелось бы узнать такие фоновые процессы в целом могут убиваться ОС из за того, что она посчитала их как зобми процессами или в ряде оптимизацией? Ну или подскажите куда еще можно копать?
возможно OOM, смотри доги, но в любом случае переписывать на systemd, по закрытию ssh процесс при попытки записи в stderr должен падать по идее
Обычно это должно в лог kern.log отправлять подобные штуки, хотя если это связано с jvm возможно надо другую утилиту использовать за наблюдением за процессом. В логах приложения тоже нет ошибок там есть lifecycle onstop он вызывается когда приложению посылают кило
для этого можно nohup использовать, чтобы в файлы писал или в /dev/null. Я так делал для одной задачи.
в /var/log/messages/var/log/syslog
можно, но не нужно.
Гляну спасибо
Тоже посмотрю спасибо
если нужно помониторить в ручном режиме, то лучше screen использовать.
Обсуждают сегодня