14.02.2023 03:58
kt97679 20 5700 Источник

Иногда бывает нужно сделать так, чтобы в каждый момент времени работало не больше одного экземпляра вашего bash скрипта. Если на вашей платформе есть команда flock, то это сделать достаточно просто:


#!/bin/bash

LOCK_FILE=/tmp/my-script.lock
LOCK_FD=9

get_lock() {
    # need to use eval here for proper expansion
    eval "exec $LOCK_FD>$LOCK_FILE"
    flock -n $LOCK_FD
}

get_lock || exit

# ...

Используя этот подход необходимо помнить, что все дочерние процессы наследуют дескрипторы файлов, открытых родительским процессом. У меня был скрипт, который запускался из крона. Этот скрипт стартовал ssh-agent, если он еще не был запущен, и выполнял через ssh команды на нескольких серверах. ssh-agent наследовал дескриптор лок файла и как следствие скрипт выполнялся только один раз при запуске ssh-agent. Для избежания подобной ситуации необходимо явно закрыть лок файл при вызове команды, которая порождает дочерний процесс. В моем случае пришлось сделать так:


#!/bin/bash

LOCK_FILE=/tmp/my-script.lock
LOCK_FD=9
SSH_KEY=/root/.ssh/id_rsa.for.ssh-agent

get_lock() {
    # need to use eval here for proper expansion
    eval "exec $LOCK_FD>$LOCK_FILE"
    flock -n $LOCK_FD
}

get_lock || exit

socket=$(find /tmp/ssh-*/agent.* -user root 2>/dev/null || true)
if [ -z "$socket" ]; then
    # need to use eval here for proper expansion
    # we need to close explicitly fd of the lock file
    # otherwise open fd is kept by ssh-agent and lock can't be aquired until ssh-agent exits
    eval ". <(ssh-agent $LOCK_FD>&-)"
    ssh-add $SSH_KEY
    return
else
# ...
fi
#...

Если по какой-то причине вы не можете использовать flock необходимую функциональность можно реализовать используя исключительно bash:


#!/bin/bash

set -u

PID_LIST=/tmp/test-get-lock.pid

get_lock() {
    local pid
    while true; do
        while read pid; do
            kill -0 $pid || continue
            [ "$pid" != "$BASHPID" ] && return 1
            echo $BASHPID >$PID_LIST.new && mv $PID_LIST.new $PID_LIST && return 0
        done < $PID_LIST
        echo $BASHPID >>$PID_LIST
    done
}

if get_lock 2>/dev/null; then
    sleep 1
    pids="$(cat $PID_LIST)"
    pid=$(echo "$pids"|head -n1)
    [ "$BASHPID" != "$pid" ] && echo "pid: $BASHPID unexpected pid: $pid $pids"
    echo "pid: $BASHPID get_lock success"
else
    echo "pid: $BASHPID get_lock failed"
fi

Вот как это работает:


  • Идентификаторы процессов (pid-ы) находятся в файле. Мы читаем pid-ы из файла и проверяем соответствуют ли они выполняющимся процессам..
  • pid-ы завершенных процессов игнорируются
  • Обнаружение pid-а выполняющегося процесса, который не соответствует текущему процессу, означает, что уже выполняется другой экземпляр скрипта и мы сообщаем о невозможности выполнения.
  • Если мы встретили pid соответствующий текущему процессу мы удаляем из файла, хранящего pid-ы, все кроме текущего pid-а (mv это атомарная операция) и продолжаем выполнение скрипта.
  • Если мы вышли из цикла проверки pid-ов мы дописываем текущий pid в конец файла и повторяем проверку. Дописывание в конец файла это атомарная операция.

Насколько это решение надежно? В процессе отладки я использовал следующую команду для тестирования:


rm -f /tmp/*.log
for x in {0000..9999}; do ./lock-test.sh >/tmp/$x.log 2>&1 & done
wait
echo "success: $(grep success /tmp/*.log|wc -l), failure: $(grep failed /tmp/*.log|wc -l), unexpected pid: $(grep unexpected /tmp/*.log|wc -l)"

Отсутствие неожиданных pid-ов означало, что код работал правильно. Для финального тестирования я использовал вот такую команду:


for y in {000..999}; do
  echo -n " $y"
  bash -c 'rm -f /tmp/*.log
    for x in {0000..9999}; do ./lock-test.sh >/tmp/$x.log 2>&1 & done
    wait' 2>/dev/null; grep unexpected /tmp/*.log && break
done

Я прогнал этот тест на своем ноутбуке с 4-х ядерным i7, на виртуальной машине с 2-мя ядрами и на сервере с 24-мя ядрами. Ни в одном из случаев проблем обнаружен не было. Тем не менее я допускаю, что мое тестирование было не исчерпывающим и предлагаемый код может сработать неправильно при каком-то стечении обстоятельств. Впрочем, если вы будете использовать данный код, для того, чтобы скрипт, запускаемый из крона, работал в единственном экземпляре, с большой вероятностью проблем не будет.

Комментарии (20)


  1. vaniacer
    00.00.0000 00:00
    #25226880
    -2

    Сохранять пид в файле, и проверять активен ли этот пид, нет?


    1. vaniacer
      00.00.0000 00:00
      #25226912

      code
      #!/bin/bash
pidf=file.pid
pid=$(cat $pidf)
[[ -e /proc/${pid:-0} ]] && { echo fail; exit 1; }

echo  $$ > $pidf
sleep $1


      1. DmitryKoterov
        00.00.0000 00:00
        #25227860
        +1

        Думаю, вы сами найдете в этом скрипте все race conditions, где оно заглючит. Блокировка - чертовски хрупкая штука в целом, когда нет нужного готового и оттестированного примитива в среде.


      1. vaniacer
        00.00.0000 00:00
        #25239674

        Можно и без файла обойтись:

        code
        #!/bin/bash
ps -ef | grep -v $$ | grep $0 && exit 1

sleep $1
echo FIN


        1. kt97679 Автор
          00.00.0000 00:00
          #25241610

          Если вы параллельно запустили редактирование vim /path/to/script ваш подход не сработает. Если случилось так, что у вашего скрипта пид 1111, а уже работает процесс с пидом 11111, то тоже не сработает.


  1. xforce
    00.00.0000 00:00
    #25227018
    +1

    Технически, PID не уникален и может быть выдан другому процесс в промежутках между проверками, а вы потом будете вечно ждать его завершения, если это что-то долгоживущее окажется.


  1. vadimr
    00.00.0000 00:00
    #25227228

    Самый простой способ – создать в /tmp файл с любым именем и дать команду rename -o mytemp.file my-script.lock my-script.lock для переименования его в my-script.lock. Нулевой код возврата из переименования – работаем, ненулевой – отваливаемся.


    1. VXP
      00.00.0000 00:00
      #25249380

      А если mytemp.file не создастся?


      1. vadimr
        00.00.0000 00:00
        #25249590

        Плохо дело, если не создаются файлы в /tmp


        1. kt97679 Автор
          00.00.0000 00:00
          #25251310

          Что делать, если скрипт завершился аварийно и не удалил my-script.lock?


          1. vadimr
            00.00.0000 00:00
            #25251318

            Надо скрипт вызывать из другого скрипта, который удаляет my-script.lock. А так вообще этот вопрос неразрешим на сто процентов, только с большой вероятностью. Может и задача на семафоре подвиснуть, и пид повторно выделиться.


            1. kt97679 Автор
              00.00.0000 00:00
              #25251398

              Но ведь при удаление my-script.lock происходит race condition?


              1. vadimr
                00.00.0000 00:00
                #25251418

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


                1. kt97679 Автор
                  00.00.0000 00:00
                  #25251456

                  А как вы поступаете в своих скриптах, использующих такой подход?


                  1. vadimr
                    00.00.0000 00:00
                    #25251474

                    Надо по смыслу операции смотреть. Обычно периодически запускаемые скрипты, которые нужно обсемафоривать, ничего не теряют от того, что какой-то один раз не запустятся.

                    Например, если это суточный бэкап в полночь, и так получилось, что он сам по себе продолжается сутки, то нам не очень важно, завершился он в 00:00:01 или в 23:59:59 – в любом случае, пропустив следующий запуск в 00:00:00, мы фактически ничего не теряем.


  1. plutarh
    00.00.0000 00:00
    #25227374

    Не претендую на сколь-нибудь полное понимание вопроса, но приведу свою версию запрета выполнения нескольких экземпляров скрипта:


    1. DmitryKoterov
      00.00.0000 00:00
      #25227894
      +1

      Здесь race condition конечно же: этот скрипт стартует одновременно дважды, оба процесса входят в ветку else, и вот вам две копии запущенные. Причем кажется, что оно должно редко происходить, но если вдруг на 10-ядерной машине окажется ненадолго load average 50 (баг где-нибудь или что-то еще), то вероятность многократно возрастает.

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


    1. AndreyUA
      00.00.0000 00:00
      #25234438
      +2

      Это какой-то вид садизма, вместо кода выкладывать скриншот из notepad++?


  1. DmitryKoterov
    00.00.0000 00:00
    #25227922

    В баше лучше однозначно flock, но его нет в MacOS! (Как это вообще возможно в 2022 году, что flock нет в MacOS и нет в Node, для меня полная загадка.)

    Вариант автора с pid-ами… ну спорно: несмотря на все тесты, есть ли четкое доказательство, что оно прям всегда работает? а с условием ротации пидов? а если Load Average искусственно загнать под сотню?

    Зато железобетонный flock есть в… Perl. И perl есть во всех OS, причем один и тот же, и запускается быстро. Поэтому если надо уж прям совсем кросс-платформенное скриптовое решение, то я использую perl + exec в нем (процесс умирает - лок сам освобождается, и за счет exec от perl-а не остается и следа в pstree).


    1. kt97679 Автор
      00.00.0000 00:00
      #25241638

      Ротация пидов действительно может вызвать проблемы. Возможно для учета не только пида, но и имени процесса, можно использовать ps -eo pid,command, но я не знаю насколько портабельно это решение.