Как аккуратные системные администраторы, нам нравится следить за тем, чтобы мелочи были так же хорошо покрыты, как и большие (когда позволяет время). Одна из этих вещей - обеспечение того, чтобы в наших системах не было битых символических ссылок.
Почему эти маленькие болтуны являются проблемой? Поскольку они заставляют вас думать, что файлы есть, когда их нет, они могут указывать на что-то более раздражающее, и потому что (маленькая) часть OCD меня сходит с ума от всех этих предупреждений при выполнении определенных команд (например grep -r).
Итак, как поступить с обнаружением (и сообщением по электронной почте или с помощью системы мониторинга) неработающих ссылок в тех частях системы, за которые отвечает администратор (нет смысла говорить мне, что ~jbloggsу них куча неработающих символических ссылок, это его проблема )?
источник
Ответы:
Проблема
-Lзаключается в том, что побочным эффектом является расширение поиска в подкаталогах, являющихся целямиsymlinks, которые могут не ожидаться или не желаться.С
GNU findutilsверсиейfind:кроме того, что не находит циклические символические ссылки.
-execdirв другом ответе он не так переносим, поэтому переходим к переносимому решению, которое находит неработающие символические ссылки, включая циклические ссылки:Смотрите этот вопрос , или ynform.org для дальнейшего обсуждения. Также см. Документацию findutils для деталей. Ссылка ynform.org также представляет метод для обнаружения только циклических ссылок.
источник
Много способов снять шкуру с кошки
Это вполне переносимо (-L это требование posix)
Вы не определили битые, вышеприведенные будут отправлять вам битые ссылки, которые не имеют цели в той части файловой системы, которая вас интересует. Он также сообщает о циклах файловой системы stderr и проблемах с символическим соединением и т. Д. Если вы тоже о них заботитесь, перенаправьте stderr на вашу почту
Если ваша находка поддерживает, это
-readableполезно и быстроВышесказанное включает в себя ссылки со слишком многими уровнями проблем символьных ссылок в его выводе, но не в циклах файловой системы.
Если части файловой системы, о которых вы заботитесь, имеют разные пути,
источник
find -Lпроблематично для этого варианта использования. См .: unix.stackexchange.com/a/38691/6860Я дам вам ответ по Linux, и вы можете при необходимости настроить его под свой Unix:
find . -type l ! -execdir test -e {} \; -print >> broken_symlinks.txt; mutt -s "Broken symlinks" womble@example.com < broken_symlinks.txt; rm -f broken_symlinks.txtВторой вариант -
ls -LR | grep 'cannot access'или некоторые изменения из команды поиска выше.Редактировать:
Да, это даже лучше
find . -type l ! -execdir test -e {} \; -print | mail -s "Broken symlinks" womble@example.comисточник
broken_symlinks.txtцеликом и просто использовать трубу? И использоватьmailвместоmuttотправки электронной почты?Это хороший способ сделать это с помощью GNU find:
Причина, по которой это работает, заключается в том, что
-lnameс-follow(или -L) «... этот тест возвращает false, если символическая ссылка не сломана», согласно странице поиска man.Вероятно, было бы целесообразно запустить такой тип сканирования диска, когда сервер не используется интенсивно. Может быть полезно использовать
niceи / илиionice(см. Этот блог для хорошего описания ionice ), чтобы уменьшить нагрузку на сервер во время выполнения этой задачи.источник
Fedora и Ubuntu предоставляют
symlinksутилиту. Утилита является собственным исполняемым файлом elf, а не сценарием оболочки оболочки. Утилита была предустановлена на Fedora. Вам может понадобиться установить утилиту в Ubuntu.С помощью
symlinksутилиты вы можете проверить наличие оборванных ссылок с помощью следующей команды.Если цели висящих ссылок можно удалить, выполните следующее, чтобы удалить их.
Вот пример вывода на сервер Fedora 31.
debian-logo.pngИubuntu-logo.pngправильны.источник