Безопасно ли отправлять SIGKILL в `git status`? - PullRequest
0 голосов
/ 02 августа 2020

Я хочу остановить Git, если запуск занимает слишком много времени git status, но Git, похоже, игнорирует SIGTERM: Почему тайм-аут не прерывает `git status`, когда он занимает слишком много времени ?

Таким образом, похоже, что один из способов обойти это - использовать SIGKILL, но вы можете столкнуться с ошибкой и повредить свой репозиторий, если отправите SIGKILL: { ссылка }

git status - это чисто запрос, поэтому разве не должно быть безопасно отправлять SIGKILL?

1 Ответ

1 голос
/ 03 августа 2020

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

Git разработан, чтобы быть достаточно устойчивым: например, вместо того, чтобы просто записывать своего индекса, он записывает обновленный индекс в файл с именем .git/index.lock, а затем использует то, что означает как процесс уровня ОС atomi c, чтобы заменить старый .git/index файл новым содержимым в .git/index.lock при вызове нового файла .git/index. Эта операция atomi c является системным вызовом rename: Git зависит от ОС, чтобы реализовать ее как операцию atomi c, которая либо полностью выполняется, либо никогда не запускается.

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

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

Когда сама ОС выходит из строя, Git может потерять файлы, без которых Git не может работать. Лучше всего для такого рода проблем иметь другое хранилище где-нибудь в другом месте, предпочтительно физически удаленном, чтобы обычное событие (например, здание загорелось, и все компьютеры в нем сгорели или были разрушены в результате пожаротушения) не повредило другое Git репозиторий. В менее крайних случаях репозиторий иногда можно восстановить на месте.

Одна из наиболее частых ошибок - это полное удаление операционной системой файла с именем .git/HEAD, а после удаления этого файла Git нет Лонг считает, что репозиторий является репозиторием. Повторно создайте файл (например, echo ref: refs/heads/master > .git/HEAD), и репозиторий вернется. Если ваша система подчиняется правилам атомарности файлов POSIX, этот конкретный случай не может произойти даже для SIGKILL.

...