Как заставить чтение и запись одного и того же файла в одном и том же конвейере всегда «терпеть неудачу»?

Скажем, у меня есть следующий скрипт:

#!/bin/bash
for i in $(seq 1000)
do
    cp /etc/passwd tmp
    cat tmp | head -1 | head -1 | head -1 > tmp  #this is the key line
    cat tmp
done

В ключевой строке я читаю и пишу один и тот же файл, tmpкоторый иногда не удается.

(Я читал, что это из-за условий гонки, потому что процессы в конвейере выполняются параллельно, что я не понимаю, почему - каждому headнужно брать данные из предыдущего, не так ли? Это НЕ мой главный вопрос, но вы можете ответить и на него.)

Когда я запускаю скрипт, он выводит около 200 строк. Есть ли способ заставить этот скрипт выводить всегда 0 строк (поэтому перенаправление ввода / вывода tmpвсегда готовится первым и поэтому данные всегда уничтожаются)? Чтобы было понятно, я имею в виду изменение системных настроек, а не этот скрипт.

Спасибо за ваши идеи.

Ответ Жиля объясняет состояние гонки. Я просто собираюсь ответить на эту часть:

Есть ли способ заставить этот скрипт выводить всегда 0 строк (поэтому перенаправление ввода / вывода на tmp всегда готовится первым и поэтому данные всегда уничтожаются)? Чтобы было понятно, я имею в виду изменение настроек системы

IDK, если инструмент для этого уже существует, но у меня есть идея, как его можно реализовать. (Но обратите внимание, что это не всегда будет 0 строк, просто полезный тестер, который легко ловит простые гонки, подобные этой, и некоторые более сложные гонки. См. Комментарий @Gilles .) Это не гарантирует, что скрипт безопасен , но может быть полезным инструментом в тестировании, аналогично тестированию многопоточной программы на разных процессорах, включая слабо упорядоченные не x86-процессоры, такие как ARM.

Вы бы запустить его как racechecker bash foo.sh

Используйте тот же системный вызов трассировки / перехват объектов , которые strace -fи ltrace -fиспользовать для крепления к каждому дочернему процессу. (В Linux это тот же ptraceсистемный вызов, который используется GDB и другими отладчиками для установки точек останова, одного шага и изменения памяти / регистров другого процесса.)

Инструмент openи openatсистемные вызовы: когда любой процесс , работающий в рамках этого инструмента делает системный вызов (или ) с , сном, может быть , 1/2 или 1 секунду. Пусть другие системные вызовы (особенно те, в том числе ) выполняются без задержки.open(2)openatO_RDONLYopenO_TRUNC

Это должно позволить автору выиграть гонку почти во всех условиях гонки, если только нагрузка на систему не была высокой или это было сложное состояние гонки, когда усечение не происходило до некоторого другого чтения. Так что случайное изменение того, какие open()s (и, возможно, read()s или записи) задерживаются , увеличит мощность обнаружения этого инструмента, но, конечно, без тестирования в течение бесконечного количества времени с имитатором задержки, который в конечном итоге охватит все возможные ситуации, с которыми вы можете столкнуться в в реальном мире, вы не можете быть уверены, что ваши сценарии свободны от гонок, если вы не прочитаете их внимательно и докажете, что это не так.

Вы, вероятно , нужно, чтобы белый список (не задержка open) для файлов /usr/binи /usr/libпоэтому процесс-старте не принимает навсегда. (Динамическое связывание во время выполнения имеет отношение к open()нескольким файлам (посмотрите strace -eopen /bin/trueили /bin/lsкогда-нибудь), хотя, если родительская оболочка сама выполняет усечение, это будет хорошо. Но для этого инструмента все равно будет хорошо не делать сценарии чрезмерно медленными).

Или, может быть, белый список каждого файла, который вызывающий процесс не имеет разрешения на обрезание. т.е. процесс трассировки может сделать access(2)системный вызов, прежде чем фактически приостановить процесс, который хотел open()файл.

racecheckerСамо по себе должно быть написано на C, а не в оболочке, но, возможно, может использовать straceкод в качестве отправной точки и может не потребовать много работы для реализации.

Вы можете получить ту же функциональность с файловой системой FUSE . Вероятно, есть пример FUSE чистой сквозной файловой системы, так что вы можете добавить в open()функцию проверки , которые переводят ее в спящий режим только для чтения, но позволяют усечению происходить сразу же.

Почему существует состояние гонки?

Две стороны трубы выполняются параллельно, а не одна за другой. Есть очень простой способ продемонстрировать это: запустить

time sleep 1 | sleep 1

Это занимает одну секунду, а не две.

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

Для наблюдения за точкой синхронизации соблюдайте следующие команды ( sh -xпечатает каждую команду по мере ее выполнения):

time sh -x -c '{ sleep 1; echo a; } | { cat; }'
time sh -x -c '{ echo a; sleep 1; } | { cat; }'
time sh -x -c '{ echo a; sleep 1; } | { sleep 1; cat; }'
time sh -x -c '{ sleep 2; echo a; } | { cat; sleep 1; }'

Играйте с вариациями, пока не освоитесь с тем, что вы наблюдаете.

Учитывая составную команду

cat tmp | head -1 > tmp

левый процесс выполняет следующее (я только перечислил шаги, которые имеют отношение к моему объяснению):

1. Запустите внешнюю программу catс аргументом tmp.
2. Открыто tmpдля чтения.
3. Пока он не достиг конца файла, прочитайте фрагмент из файла и запишите его в стандартный вывод.

Правый процесс выполняет следующие действия:

1. Перенаправить стандартный вывод на tmpусечение файла в процессе.
2. Запустите внешнюю программу headс аргументом -1.
3. Прочитайте одну строку из стандартного ввода и запишите ее в стандартный вывод.

Единственная точка синхронизации состоит в том, что right-3 ожидает, пока left-3 обработает одну полную строку. Синхронизация между left-2 и right-1 отсутствует, поэтому они могут происходить в любом порядке. В каком порядке они происходят, непредсказуемо: это зависит от архитектуры ЦП, от оболочки, от ядра, на каких ядрах планируются процессы, какие прерывания получает ЦП в это время и т. Д.

Как изменить поведение

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

Хорошо, есть один «системный параметр», который вы можете изменить: вы можете заменить /bin/bashего другой программой, отличной от bash. Я надеюсь, что само собой разумеется, что это не очень хорошая идея.

Если вы хотите, чтобы усечение происходило до левой стороны канала, вам нужно поместить его вне конвейера, например:

{ cat tmp | head -1; } >tmp

или

( exec >tmp; cat tmp | head -1 )

Я понятия не имею, почему ты этого хочешь. Какой смысл читать из файла, который, как вы знаете, пуст?

И наоборот, если вы хотите, чтобы перенаправление вывода (включая усечение) происходило после catзавершения чтения, то вам необходимо либо полностью буферизовать данные в памяти, например:

line=$(cat tmp | head -1)
printf %s "$line" >tmp

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

cat tmp | head -1 >new && mv new tmp

Коллекция moreutils включает в себя программу под названием sponge.

cat tmp | head -1 | sponge tmp

Как автоматически определить проблему

Если вашей целью было взять плохо написанные сценарии и автоматически выяснить, где они ломаются, то извините, жизнь не так проста. Анализ во время выполнения не может надежно найти проблему, потому что иногда catзаканчивает чтение до того, как произойдет усечение. Статический анализ в принципе может это сделать; Shellcheck поймал упрощенный пример в вашем вопросе , но он может не уловить подобную проблему в более сложном скрипте.