Como ordenados administradores de sistemas, nos gusta asegurarnos de que las pequeñas cosas estén tan bien cubiertas como las grandes (cuando el tiempo lo permite). Una de estas cosas es garantizar que nuestros sistemas no estén llenos de enlaces simbólicos rotos.
¿Por qué son estos pequeños blighters un problema? Debido a que te hacen pensar que los archivos están allí cuando no lo están, pueden ser una indicación de algo más molesto, y porque la parte (pequeña) de mi TOC se vuelve loca con todas esas advertencias al ejecutar ciertos comandos (como grep -r).
Entonces, ¿cómo se podría detectar (e informar, a través del correo electrónico o el sistema de monitoreo) los enlaces rotos en las partes de un sistema de las que es responsable el administrador (no tiene sentido decirme que ~jbloggstiene un montón de enlaces simbólicos rotos, ese es su problema )?
fuente
Respuestas:
El problema con esto
-Les que tiene el efecto secundario de expandir la búsqueda en subdirectorios que son el objetivo desymlinks, lo que podría no ser esperado o deseado.Con
GNU findutilsversión defind:excepto que no encuentra enlaces simbólicos cíclicos.
-execdiren la otra respuesta no es tan portátil, por lo que lo destilamos a una solución portátil que encuentra enlaces simbólicos rotos, incluidos enlaces cíclicos:Vea esta pregunta , o ynform.org para más discusión. Consulte también la documentación de findutils para más detalles. El enlace ynform.org también presenta un método para detectar solo enlaces cíclicos.
fuente
Muchas formas de pelar un gato
Esto es bastante portátil (-L es un requisito posix)
No definió roto, lo anterior le enviaría enlaces rotos que no tienen objetivo en la parte del sistema de archivos que le interesa. También informa sobre bucles del sistema de archivos stderr y demasiados niveles de problemas de enlaces simbólicos, etc. Si también te importan, redirige stderr a tu correo
Si su búsqueda es compatible,
-readablees útil y rápidoLo anterior incluye enlaces con demasiados niveles de problemas de enlaces simbólicos en su salida pero no bucles del sistema de archivos.
Si las partes del sistema de archivos que le interesan tienen rutas diferentes, entonces
fuente
find -Les problemático para este caso de uso. Ver: unix.stackexchange.com/a/38691/6860Le daré una respuesta de Linux y puede ajustarla a su Unix, si es necesario:
find . -type l ! -execdir test -e {} \; -print >> broken_symlinks.txt; mutt -s "Broken symlinks" [email protected] < broken_symlinks.txt; rm -f broken_symlinks.txtLa segunda opción es
ls -LR | grep 'cannot access'o algunas modificaciones del comando find anterior.Editar:
Sí, esto es aún mejor:
find . -type l ! -execdir test -e {} \; -print | mail -s "Broken symlinks" [email protected]fuente
broken_symlinks.txtcompleto y simplemente usar una tubería? ¿Y usar enmaillugar demuttenviar el correo electrónico?Esta es una buena manera de hacerlo con GNU find:
La razón por la que esto funciona es porque
-lnamecon-follow(o -L) "... esta prueba devuelve falso a menos que el enlace simbólico esté roto", de acuerdo con la página del manual de búsqueda.Probablemente sería aconsejable ejecutar este tipo de escaneo de disco cuando el servidor no se usa mucho. Puede ser útil usar
nicey / oionice(ver este blog para una buena descripción de ionice ) para reducir la carga en el servidor mientras se ejecuta esta tarea.fuente
Fedora y Ubuntu proporcionan la
symlinksutilidad. La utilidad es un ejecutable elfo nativo y no un script de shell envoltorio. La utilidad fue preinstalada en Fedora. Es posible que deba instalar la utilidad en Ubuntu.Con la
symlinksutilidad puede auditar enlaces colgantes con el siguiente comando.Si los destinos de los enlaces colgantes están bien para eliminarlos, emita lo siguiente para eliminarlos.
Aquí hay un ejemplo de la salida en un servidor Fedora 31. Los
debian-logo.pngyubuntu-logo.pngson correctos.fuente