Что делает nginx-s, вновь открылись, делают?

Давайте посмотрим то, что произошло, и что (если что-нибудь) может делаться с этим.

sudo find / -type d -exec chmod -Rf a-wr {} \;

Это ломается к некоторым довольно простым частям:

sudo find / -type d

Безопасный в и себя. Это просто генерирует список всех каталогов (это что -type d для) в файловой системе.

-exec

Для каждой записи в списке выполните данную команду

chmod -Rf a-wr {}

Теперь мы становимся серьезными. {} расширяется до текущей записи списка, таким образом, команда, выполняемая для каждого каталога, chmod -Rf a-wr $DIRNAME. К chmod, -R означает рекурсивную операцию, -f подавляет вывод сообщения об ошибке, и a-wr удаляет запись, и прочитайте разрешение от всех пользователей (a обозначает all, который отличен от, например. o для невладельцев).

\;

Конец командной строки для выполнения.

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

chmod --recursive --quiet a-wr /

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

Может быть возможно восстановиться с этого путем переустановки пакетов, которые Вы установили, но это не поможет ничему в, например, Вашему корневому каталогу, и нет никакой гарантии, это будет работать вообще. Вам будет нужна соответствующая архитектура живой CD (я рекомендовал бы живой CD той же ОС, которую Вы используете), начальная загрузка с помощью него, смонтируйте корневую файловую систему и опуститесь до оболочки. Затем chroot /mnt /bin/bash где/mnt является точкой монтирования для системной корневой файловой системы, сопровождаемой mount -a смонтировать остающиеся файловые системы.

Однажды там, dpkg -u --reinstall install '.+' должен переустановить все пакеты, восстановив большую часть поломки. Обратите внимание, что потребуется большое время для завершения.

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

find /home/me -not -type d -exec chmod 640 {} \;
find /home/me -type d -exec chmod 750 {} \;

Это установит все каталоги на пользователя, читал/писал/выполнял, группа читала/выполняла, другие никакой доступ и некаталоги к пользовательскому чтению-записи, чтению группы, другие никакой доступ, который является разумной базовой линией.

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

Намного более легкая альтернатива, если бы у Вас есть они, должна была бы практиковать Ваши резервные методы восстановления.

6
25.02.2015, 16:51
1 ответ

Что-то случилось. Вы просто не заметили :) Вызов nginx -s reopen или отправка сигнала SIGUSR1 в процесс nginx, в результате чего nginx снова открывает свои лог-файлы.

Это может быть удобно в том случае, если вы (или такая программа, как logrotate) измените лог-файл и захотите, чтобы nginx обновил свои файловые дескрипторы. При этом nginx помещает курсор записи в (новый) конец файла и предотвращает повреждения журнала (что произойдет, если nginx запишет запись с неправильным/устарелым смещением файла).

5
27.01.2020, 20:28

Теги

Похожие вопросы