Я бы предложил записать PID (в bash, который находится в $!
после запуска процесса) в файл, из двух процессы, которые вы запускаете ( psdash
и kegbot
).
Затем вы можете использовать ps --pid $ (cat your.pid) | тр-с '' | sed 1d | cur -d '' -f4
, чтобы увидеть, действительно ли процесс запущен.
В качестве примечания, вы всегда должны проверять, действителен ли PID внутри файла .pid
, прежде чем действовать по нему!
Может случиться так, что любой механизм, который вы используете для удаления файла .pid
, когда ваши программы останавливаются (обычно это будет либо часть самой программы, либо оболочка сценария оболочки), выйдет из строя, и появится "неправильный" PID в файле .pid
. Если файл .pid
выживает после перезагрузки, в худшем случае будет PID какого-то другого процесса, с которым вы будете действовать.
Хорошо, вот возможное решение на примере kegbot
:
Сначала вам понадобится сценарий оболочки. Для простоты предположим, что все происходит в вашем $ HOME
.
Итак, простая оболочка ( run_kegbot.sh
) будет выглядеть так:
#!/bin/zsh
kegbot runserver xxx.xx.x.xxx:8008
echo $! > kegbot.pid
wait
rm -rf kegbot.pid
Это одно из решений, если kegbot
переходит в фоновый режим и т. Д., Но PID действует после развилки. Я не знаю, может ли kegbot
обрабатывать файлы PID самостоятельно, что избавило бы вас от необходимости обрабатывать файлы PID самостоятельно.Или, может быть, вы можете сделать так, чтобы kegbot
не переходил в фоновый режим, а затем использовать саму оболочку (добавив &
в конец строки 2), чтобы записать файл PID и дождитесь его завершения.
В любом случае, после того, как вы сделаете ошибку в PID-файле, вам понадобится что-то вроде этого в вашем .profile
:
[ -e kegbot.pid ] && {
PID=$(cat kegbot.pid)
COMM=$(ps -p $PID -o comm=)
[ "x$COMM" != "xkegbot" ] && rm -f kegbot.pid
}
[ -e kegbot.pid ] || screen -d -m ./run_kegbot.sh
Опять же, это всего лишь одно решение проблемы, но общая идея состоит в том, чтобы использовать PID процесса, чтобы проверить, запущен он или нет, и один из способов сделать это - выше.
Некоторые демоны хранят свои PID-файлы в / var / run /
, если kegbot
и / или psdash
делают это, вам, очевидно, не нужен сценарий оболочки и т. д., так как вы можете напрямую использовать эти файлы PID.
Вам определенно нужно проверить, действительно ли PID в файле PID является процессом, которому он принадлежит. Неправильная перезагрузка и / или сбой демона могут оставить зомбированный файл PID и т. Д. Для этого и предназначен первый тест файла PID, приведенный выше.
Да, обычно пользователь root имеет достаточные привилегии для косвенного изменения кода ядра, хотя существуют механизмы, которые можно использовать для ограничения этого, при условии, что приняты достаточные меры безопасности. Неполный -список способов, с помощью которых привилегированный пользователь root может изменять код ядра :
.Системные вызовы ioperm()
и iopl()
могут устанавливать разрешения порта ввода/вывода.
Естественно, файлы в загрузочном каталоге (, включая ядро ), могут быть изменены.
Символьные устройства /dev/mem
, /dev/kmem
и /dev/port
обеспечивают прямой доступ к памяти.
Различные MSR могут использоваться для изменения поведения -ЦП на низком уровне, нарушая безопасность.
Функцию kexec
можно использовать для загрузки нового ядра.
Таблицы ACPI могут быть загружены пользователем root во время выполнения, выполняя AML в ядре.
ACPI custom_method
можно использовать для прямой записи в память.
Модули ядра могут быть загружены пользователем root, если подписание модулей отключено.
Функции отладки, такие как kprobes, могут изменить поведение ядра.
Смягчение может быть выполнено либо с помощью усиленного ядра, такого как правильно сконфигурированное grsecurity , либо с помощью исправлений блокировки ядра , которые теперь являются исходными .Еще нужно, конечно, запретить пользователю root писать в загрузчик или загрузочный раздел, где живут ядра.