[Вакансия, Москва] Системный администратор / Linux-специалист, ООО Финам, до 100 т.р.

PID=`cat /tmp/block.pid`
if [[ `cat /proc/$PID/comm` != «assa» ]; then
fi
:) еще проще

kill -0 популярная штука :)

Операцию на гландах вполне можно делать через задний проход пациента. KILL -0 - это классический пример.

Для проверки существования процесса есть вполне конкретные и _безопасные_ механизмы - /proc, ps (которая по-существу просто парсит /proc). Нахрена изобретать колесную пару? :)

Завтра разработчикам придет в моск идея использовать -0 как -9 - и полинета ляжет с такими-то «идеальными» применениями. :) Я еще раз поржу.

Насколько я понимаю, одному странному человеку взбрело в голову это использовать. Другой подцепил заразу в стиле «это КРУТО, это ГРЯЗНЫЙ ХАК». :)
Чем гордиться-то? Тем, что ты ps и /proc использовать не умеешь?
Или девочкам в уши заливать, что ты крутой перец и через kill существование процесса проверяешь?

Еще раз (уже в последний) повторяю: быть уверенным в том, что kill -0 не вызовет завершение или зомби процесса лично я не могу. Учитывая, что данный пид может быть занят программой потенциально подверженной такой возможности, я не считаю использование kill -0 безопасным.

Proc платформозависим, ps-utils нет. Реакция системы на kill с нулём в качестве номера сигнала описана в стандарте Posix (т.е. тоже платформонезависима в рамках большинства юниксов): http://pubs.opengroup.org/onlinepubs/009695399/functions/kill.html

Конечно, если разработчики ядра ВНЕЗАПНО решат забить на Posix, то ляжет пол-интернета (серьёзно, потому что kill 0 активно используется, например, апачем при общении с форкнутыми ча,лдами, ЕМНИП).

> Товарищ idle, вы к чему пукнули?

если бы тебе было меньше 12ти, я бы попытался тебе обьяснить,
что хорошие мальчики в технических дискуссиях стараются не
употреблять подобные выражения.

но тебе, наверное, больше. так что даже не знаю. наверняка
твои родители хотели сделать человека, у них не получилось.
это бывает.

Я даже и не знаю, смеяться мне или плакать...

да не переживай ты так. знания - дело наживное, здесь ты еще
можешь наверстать.

Вы этот man sigprocmask хотя бы сами почитали??? :)

нет, если честно. но мне не нужно читать man 2, я знаю предмет
лучше его авторов.

и не надо его здесь бездумно цитировать. лучше прочти, и
попытайся понять.

SIG_BLOCK и _есть_ то, что kill -0 посылает в соответствии

сопределением в glibc

нет.

КАК_ обработать этот сигнал - решает сам процесс

нет. хмм, специально для тебя заглянул в man kill...

If sig is 0, then no signal is sent, but error checking
is still performed.

Я гляжу, пятизвездный idle - как раз тоже из того аула

«горе-админов», которые по вечерам понедельников судорожно

восстанавливают упавший постгрес. ГЫ.

полагаю, ты и на собеседовании так себя вел?

ух ты, тут уже следующая страница, не заметил сразу...

if [[ `cat /proc/$PID/comm` != «assa» ]; then

еще одно свидетельство твоей некомпететности.

ты хоть понимаешь, что comm не может однозначно
идентифицировать процесс?

ты знаешь, что в этот файл можно писать?

кстати, он появился только в 2.6.33. например, на моей
машине его нет.

какой же ты неуемный. и неумный.

Тем, что ты ps и /proc использовать не умеешь?

тебе уже сказали, что /proc платформозависим. наконец,
его может просто не быть, даже под linux. не говоря уже
о том, что это просто плохая идея.

Или девочкам в уши заливать, что ты крутой перец и через kill

да у тебя и здесь проблемы...

Завтра разработчикам придет в моск идея использовать -0 как -9

ага, ага. а еще они могут переделать ps в rm.

Еще раз

жги!

(уже в последний)

я искренне на это надеюсь

быть уверенным в том, что kill -0 не вызовет завершение

или зомби процесса лично я не могу.

разумеется, ты не можешь. ты просто недостаточно знаешь.

kill -0 это не хак, это документированная и широко используемая
фича. и даже POSIX про это знает (как подсказывает anonymous).

однако. у нас прогресс! еще вчера ты уверенно утверждал:
«КАК_ обработать этот сигнал - решает сам процесс». сегодня
ты уже так не думаешь.

нет, нет, что ты. я не рассчитываю, что ты признаешь, что был
не прав. про извинения за лексикон с твоей стороны я вообще
даже не думаю.

> Ок. Есть проблема: какой-то процесс читает что-то из БД во внутренний буфер сложным запросом с множеством джоинов. ВНЕЗАПНО ответ больше RAM+swap, серверу резко плохеет, SSH-сессия не устанавливается

Давай, анонимус, ты заинтриговал меня!

Что мне делать, расскажи же!!!

Неужели тупо ограничить размер доступной для выделения виртуальной памяти, чтобы процесс умирал быстрее - это и есть твоя серебряная пуля?

Посвяти нас в тайну, прошу тебя, о великий анонимус!!!

Разве я говорил о серебряной пуле? Мне просто стало интересно: в какой великой базе знаний человечества su будет искать решение такой простой проблемы.

А так вариантов много, от возни с оверкоммитом/limits через тупое добавление памяти/свопа машине до снифа запросов (пускай это mysql) связкой tcpdump/mk-query-digest и последующей вставкой mysql-proxy между приложением и Бд с «заглушками» на проблемные запросы. В зависимости от того, на что фантазии хватит, насколько жесткие SLA и насколько чОрной коробкой является приложение.

> #!/bin/sh

pidfile=/tmp/block.pid

if [ -s ${pidfile} ] && kill -0 `cat ${pidfile}` 2>/dev/null; then exit;

fi

echo $$ > ${pidfile}

# do something

rm -f $pidfile

Давайте разберёмся.

Мы пытаемся сделать что-нибудь, но при этом хочется, чтобы мы были единственным процессом в системе, который это делает, так?

Нам хочется, чтобы вне зависимости от обстоятельств, наш скрипт продолжал функционировать. В частности, хочется, чтобы скрипт вёл себя корректно и при некорректном состоянии системы, например при наличии старых файлов, содержащих некорректные pid. А также нельзя допустить, чтобы наш скрипт дал в руки злоумышленнику дополнительный инструмент для нанесения вреда системе.

1. Используется /tmp, где каждый злоумышленник может разместить symlink с нужным именем, чтобы записать в какой-нибудь файл последовательность символов из множества [0-9] с переводом строки в конце. Можно снести какой-нибудь очень нужный файл БД таким образом, если поставить себе такую цель.

2. Между моментом проверки на существование файла и созданием нового файла с pid'ом текущего процесса имеется некий ненулевой интервал времени, в течение которого проверка на существование файла возвращает тот же результат - файл не существует, то есть имеется ненулевая вероятность того, что точно такой же процесс запишет уже свой пид вместо нашего, а кроме этого, выполнит параллельно с нами нашу работу.

3. То же верно и для случая, когда файл существует, но в нём записан pid несуществующего процесса. Между моментом проверки pid'а и моментом записи нашего pid'а в файл имеется ненулевой интервал времени.

4. Файл с pid'ом может указывать на pid не относящийся УЖЕ к нашей задаче. В случае, если это окажется будет pid долгоживущего системного процесса (syslog, crond, потоки ядра), наша задача перестанет работать без видимых на то причин до следующей перезагрузки. Так будет происходить очень редко, но регулярно, вызывая бессильную злобу и желание всё оторвать у человека это написавшего.

Выводы.

Системные вызовы для установления блокировок не являются излишеством, созданным для удобства низкоквалифицированных сисадминов, не умеющих писать шесть строчек на shell. Они являются необходимостью, без них - нельзя решить определённый круг задач.

man 1 flock из пакета util-linux

mkdir /var/tmp/lockdir; chown script-user /var/tmp/lockdir; chmod go-rwx /var/tmp/lockdir; touch /var/tmp/lockdir/lockfile; flock -nb /var/tmp/lockdir/lockfile -c «делаем наш любимый do something»

Если хочется сохранять ещё и свой pid для чего-нибудь, то делать это надо уже внутри блокировки.