LINUX.ORG.RU
ФорумJob

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


0

2

Компании (спец-группе внутри компании Финам), занимающейся разработкой высоконагруженных веб-проектов, в связи с запуском нового проекта, требуется системный администратор / Linux-специалист.

Обязанности:

  • участие в развитии существующей инфраструктуры;
  • проектирование и запуск новых сервисов;
  • техническое обслуживание существующих и ввод в эксплуатацию новых серверов и сетевого оборудования.

Требования к кандидатам:

  • знания GNU/Linux (предпочтительно RedHat Enterprise Linux, CentOS, Fedora);
  • твёрдые знания, опыт настройки и эксплуатации программного обеспечения: apache, mod_php, nginx, PostgreSQL и MySQL, subversion/git;
  • знание sh / awk / sed, perl;
  • опыт написания политик iptables;
  • свободное чтение документации на английском, хороший уровень русского языка.

Желательно:

  • опыт работы с cfengine, drbd, heartbeat и ocfs2, php-fpm;
  • опыт работы с FreeBSD;
  • опыт сборки и создания RPM пакетов, mock;
  • опыт работы с сетевым оборудованием Cisco, 3Com;
  • системы мониторинга cacti (rrdtool), nagios, net-snmp;
  • системы резервного копирования;
  • предпочтение отдаётся кандидатам с хорошим техническим образованием (МГУ, МФТИ, МГТУ и пр.).

Условия:

  • талантливый коллектив опытных разработчиков, дружеская обстановка;
  • офис в центре Москвы (м. Тверская-Чеховская-Пушкинская);
  • медицинская страховка;
  • поощрение любознательности, семинары/конференции/обучение;
  • уровень оплаты: 60000-100000 руб. по результатам собеседования.

Вопросы/резюме: vodmal at яндекс.ру, в топик или через МойКруг


Ответ на: комментарий от VoDmAl

>это признак закостенелости мышления

Дело твое. Это - религия. Далекооо не всегда оправданная.

с целью решить её максимально эффективным способом на текущий момент


Ключевая фраза «на текущий момент». Не «навсегда» и даже не «на длительный срок», а просто «на текущий момент». Результат - судорожные попытки поднять БД в семь часов вечера понедельника...

Я искал человека к себе в команду, поэтому мне было нужно личное общение. Понимаешь? Поэтому ни телефон, ни скайп.


Ну и общался бы лично. Зачем это дурацкое собеседование по мобиле? В конце-концов, можно было бы провести в 2 этапа: сначала с Артёмом (LOL!) удаленно, потом в зависимости от результатов - с тобой лично.

6 строчек, которые отсеивают и ленивых и чрезмерно необоснованно самоуверенных и не готовых интегрироваться в инфраструктуру с уже существующими решениями!


Ладно. Я действительно не понял, что же эта хрень делала... После объяснения назначения этого чуда... ну по порядку. Ржем все вместе:

Какие потенциальные проблемы или проблема кроется в следующем фрагменте кода:
#!/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

По твоим словам, вы это чудо применяете в ПРОДАКШН системе...

Сигнал 0 не определен в signal.h, но определен в signal-defs.h:

root@r00t:/usr/src/linux/include/asm-generic# cat ./signal-defs.h | grep SIG_BLOCK | grep define
#define SIG_BLOCK          0    /* for blocking signals */

Такой сигнал описан в http://isp.vsi.ru/library/Programmer/glibc/libc_373.html
«Generally, a program does not block signals indefinitely--it might as well ignore them....»
То есть, программа в принципе может просто проигнорировать сигнал и НЕ будет убита командой kill -0.

Да, там проблемы с правами (пид-файл в /tmp), да там у кого-то еще где-то может не хватить прав в системе.
Но самая большая проблема (и это ведь я объяснил на собеседовании!) - вы используете 'kill -0' для проверки существования процесса!!! Потенциально, вы просто посылаете 0-й сигнал «какому-то» процессу (например - пид-файл существует, но интересный вам процесс давно умер и данный ПИД занял, например, постгрес)... который после такого внезапно свалившегося щастя может и в зомби выпасть и просто прекратиться! :) ыыы
По идее, _корректный_ скрипт проверки существования интересующей софтинки должен бы выглядеть примерно так:
#!/bin/bash

PIDFILE=«/var/run/assa.pid»
PIDPROC=`/bin/cat $PIDFILE`

if [[ `/bin/ps -e -o pid,command | /bin/grep $PIDPROC | /bin/grep -v «grep» | /bin/cut -d " " -f3`!=«путь_и_имя_программы» ]]; then
# тут делаем твое dosomething
fi
Дарю код. Можете применять.

театр абсурда и т.д. даже комментировать не буду


И не надо.

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


Видишь ли, при отсылке резюме я не знал, что это - финамовский проект (может, вакансию невнимательно прочел, может там и небыло написано про Финам). Потом же, когда выяснилось - поздняк метаться. Решил сходить посмотреть, вдруг чего интересное расскажут.

su
()
Ответ на: комментарий от su

> Сигнал 0 не определен в signal.h

потому, что такого сигнала нет. а вот kill(pid, 0) есть, да.

#define SIG_BLOCK 0 /* for blocking signals */

Такой сигнал описан в



это не сигнал. man sigprocmask

Но самая большая проблема (и это ведь я объяснил на

собеседовании!) - вы используете 'kill -0' для проверки


существования процесса!!!



и совершенно правильно.

который после такого внезапно свалившегося щастя может

и в зомби выпасть и просто прекратиться! :)



не может.

ыыы


это правильно ;)

idle ★★★★★
()
Ответ на: комментарий от idle

пардонте за наивный нубский вопрос. ps уже для определения существования процесса не комильфо?

anonymous
()
Ответ на: комментарий от idle

>> Сигнал 0 не определен в signal.h

потому, что такого сигнала нет


Вот я и пытаюсь понять, чего же idle хотел этой фразой сказать. Первоисточник - как раз и есть signal.h. Раз там сигнал 0 не определен (и это было отмечено), то его и нет, что абсолютно логично. Товарищ idle, вы к чему пукнули?

это не сигнал. man sigprocmask


Я даже и не знаю, смеяться мне или плакать...
Вы этот man sigprocmask хотя бы сами почитали??? :)

NAME
sigprocmask - examine and change blocked signals

SYNOPSIS
#include <signal.h>

int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

sigprocmask(): _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE

DESCRIPTION
sigprocmask() is used to fetch and/or change the signal mask of the calling thread. The signal mask
is the set of signals whose delivery is currently blocked for the caller (see also signal(7) for more
details).

The behavior of the call is dependent on the value of how, as follows.

и совершенно правильно

не может



SIG_BLOCK
The set of blocked signals is the union of the current set and the set argument.

SIG_BLOCK и _есть_ то, что kill -0 посылает в соответствии с определением в glibc. _КАК_ обработать этот сигнал - решает сам процесс: проигнорировать, выпасть в зомби, завершиться...
Именно в этом и есть чудовищный идиотизм примененного Артёмом «ноу-хау». :)
Я гляжу, пятизвездный idle - как раз тоже из того аула «горе-админов», которые по вечерам понедельников судорожно восстанавливают упавший постгрес. ГЫ.


это правильно ;)


Действительно, есть над чем поржать.

su
()
Ответ на: комментарий от su

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

kill -0 ничего никому не пошлёт, но вернёт «ESRCH (No such process)», если процесса с таким пидом нет.

«Дарю код. Можете применять.» — ну давай применим:
---
$ PIDPROC=11; /bin/ps -e -o pid,command | /bin/grep $PIDPROC | /bin/grep -v «grep» | /bin/cut -d " " -f3

411
nrpe
ssh
/usr/bin/perl


-

-d
ls

xx@pts/11
---
Один пид может оказаться подстрокой другого, ок. И вероятность этого выше, чем то, что кто-то уже занял тот же пид, что был у нашего отвалившегося процесса.

Если уж очень хочеться быть уверенным в том, что лок-файл не stale, а с данным пидом запущен тот самый, нужный процесс, то я бы сделал что-т такое (опять, from the top of my head):
---
#!/bin/bash

if /usr/sbin/lsof -nP /tmp/mlock >/dev/null ; then exit 0; fi

exec 3<>/tmp/mlock
echo $$ >&3
...
---
Т.е. мы не просто пид в лок пишем, но и fd на него открываем. Можно вставить обработку всяких разных неприятных ситуаций: есть лок И fd открыт — всё ок; есть лок, нет fd — stale pid, процесс отстрелили/свалился; есть fd, нет лока — кто-то снёс лок-файл.

Но вообще и то, что есть у них сейчас будет работать в нормальных условиях.

Про glibc, дефайны и т.п. — ну зачем ты туда полез вообще? Ну не можешь читать код ядра (нечего стыдиться, очень мало кто может) — не лезь. Погуглил бы лучше, увидел бы, что kill -0 популярная штука :)

anonymous
()
Ответ на: комментарий от su

Да, если уж очень хочеться именно ps, ну не делайте вы эти уродливые `ps .. |grep ..|grep -v grep|cut/awk`, а. Ну ведь можно же красиво и кратко, а-ля:
if [ `pgrep -of $0` -eq `cat /tmp/block.pid` ]; then exit 0; fi
echo $$ >/tmp/block.pid
[...]

anonymous
()
Ответ на: комментарий от anonymous



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


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

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

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

su
()
Ответ на: комментарий от anonymous

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

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

su
()
Ответ на: комментарий от su

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

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

anonymous
()
Ответ на: комментарий от su

> Товарищ 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 - как раз тоже из того аула

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


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



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

idle ★★★★★
()
Ответ на: комментарий от su

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

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


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

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

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

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

idle ★★★★★
()
Ответ на: комментарий от su

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

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


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

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


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

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


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

Еще раз


жги!

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


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

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

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



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

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

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

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

idle ★★★★★
()
Ответ на: комментарий от su

> #!/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 для чего-нибудь, то делать это надо уже внутри блокировки.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.