¿Puede bash salir de la sincronización con el sistema de archivos?

Puede que no esté formulando mi pregunta correctamente, pero haré todo lo posible para explicar los síntomas que estoy experimentando. Primero, por contexto, estoy ejecutando un servidor Ubuntu (sin GUI), versión 12.04.3 LTS (de acuerdo con la utilidad lsb_release). En general, hago todo mi trabajo en tmux, me conecto al servidor a través de Putty y uso vim para toda mi edición de texto.

Ahora para los síntomas. Como uso tmux, generalmente tengo algunas ventanas abiertas en todo momento. Uno de ellos alberga un servidor de nodo con el que he estado jugando, y vive en un subdirectorio de la casa de mi cuenta de usuario (específicamente ~/battleship). El servidor interactúa con una página web que también alojo fuera del servidor usando nginx, y todo el código del sitio web reside /usr/share/nginx/www/bs(también mantengo una ventana separada abierta para editar la fuente del cliente). Lo que sucede es que después de varias horas de dejar la ventana del servidor inactiva y sin tocar, parece que no se sincroniza. Puedo ejecutar lsy ver los archivos, y puedo abrirlos para editarlos ( vim server.js). Sin embargo, cuando hago eso, independientemente de si hago cambios y guardo o simplemente salgo al instante, cuando ejecutolsde nuevo veo un archivo .server.js.swp y ninguno de mis cambios (si hice alguno) persiste. Si me muevo fuera de ese directorio y luego vuelvo a entrar, se corrige solo: puedo abrir el archivo y editarlo con éxito, sin dejar un .swp cuando lo cierro. Mencioné la mitad de las cosas del origen del cliente porque me di cuenta de que esto no sucede en la carpeta / www (presumiblemente porque está fuera del directorio de inicio de mi cuenta de usuario).

Después de ese muro de texto, mi pregunta es la siguiente: ¿Alguien sabe por qué sucede esto y cómo evitarlo? Solo puedo imaginar que hay alguna manera, considerando que este no es el único servidor Linux al que me conecto a través de Putty y uso tmux / vim, y sin embargo, es el único en el que ocurre este comportamiento extraño. Cualquier ayuda sería apreciada.

Nota: etiqueté esto con bash, tmux y masilla porque supongo que uno de ellos tiene la culpa, pero realmente no tengo idea de cuál.

Actualización: Esta es la salida de cat /proc/mountlo solicitado por Gilles (aunque con mi nombre de usuario y los valores de ecryptfs_fnek_sigy ecryptfs_sigcensurado, porque si bien no sé cuáles son esas dos cosas, parecen estar relacionadas con el cifrado, y es mejor prevenir que lamentar).

rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=2008532k,nr_inodes=502133,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=807840k,mode=755 0 0
/dev/disk/by-uuid/2da27263-f079-47ba-90ad-66e4c3a53810 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
/home/[username]/.Private /home/[username] ecryptfs rw,relatime,ecryptfs_fnek_sig=[censored],ecryptfs_sig=[censored],ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0

Actualización 2: Aquí está el resultado de uname -a:

Linux [server-name] 3.5.0-39-generic #60~precise1-Ubuntu SMP Wed Aug 14 15:38:41 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Actualización 3: Completé un pase de memtest. Este es el resultado de dicha prueba . Parece haberse completado sin errores, por lo que no estoy seguro de si terminará ayudando con algo. También puede ver algunos detalles de hardware en caso de que ayude de alguna manera.

bash putty tmux

— Alex
fuente

No, bash no puede "desincronizarse con el sistema de archivos", y eso no es lo que sucede de todos modos. Es más como si el sistema de archivos no estuviera sincronizado con el sistema de archivos. Definitivamente es un problema, y extraño en eso. ¿Qué sistema (s) de archivos está utilizando (publicar la salida de cat /proc/mounts)? Este es probablemente un servidor virtualizado, ¿qué tipo de virtualización está usando?

— Gilles 'SO- deja de ser malvado'

@Gilles Actualicé la pregunta para incluir la salida de cat /proc/mountsusted. Espero que eso signifique algo para usted: todavía soy bastante nuevo en Linux, por lo que aprendí mucho y todavía no he jugado con el sistema de archivos (más allá de usarlo).

— Alex

Entonces, el problema ocurre en un sistema de archivos ecryptfs. Esto parece un error en ecryptfs, o en otras partes del núcleo, o en el software de virtualización, si corresponde, o una falla de hardware. ¿Se está ejecutando en su propio hardware en una caja o en un estante, o se trata de un servidor virtualizado con algún proveedor de alojamiento? ¿Cuál es el resultado de uname -a? Si es su hardware, conecte una consola y haga una prueba de memoria en el próximo arranque. Si está alojado, comuníquese con su proveedor de alojamiento y describa estos síntomas.

— Gilles 'SO- deja de ser malvado'

Si ejecuta, sudo sync¿se actualizan los archivos?

— Braiam

Intente el comando de sincronización. También el df cmd es útil para mostrar dónde vive un directorio. Como / proc / mount pero salida más legible. Hacer df -h /www ~/battleship /usr/share/nginx/www/bs. ¿Es el problema con los montajes encryptfs? ¿Tal vez se necesita un procesamiento sw adicional para las escrituras en ese disco, por lo que hay almacenamiento en caché o algo sucede con eso?

— Gaoithe

Respuestas:

La única experiencia que he visto con algo como esto fue cuando se quitó un directorio y se creó uno nuevo. AIX y Solaris tuvieron este problema años atrás. Si tiene una sesión de shell abierta en un directorio eliminado, puede obtener resultados impredecibles que parecen un sistema de archivos que no está sincronizado.

bash1: mkdir test1
bash2: cd test1
bash1: touch test1/testfile
bash1: ls test1
testfile
bash2: ls
testfile
bash1: rm -rf test1
bash2: ls
???(unknown results)???

El sistema de archivos encriptados también suena como algo para revisar. ¿Has probado en un sistema de archivos sin cifrar?

Lo siento, no puedo publicar comentarios todavía. No hay suficientes puntos.

— Michael McGarrah
fuente

Esto es relevante para la pregunta, con un shell bash dejado con un directorio predeterminado que no existe y en el que es imposible crear archivos.

— ubfan1

Puedo probar este pequeño experimento, pero estoy bastante seguro de que es un problema ecryptfs. Los directorios en cuestión definitivamente todavía existen; Puedo trabajar normalmente después de un simple cd .cuando vuelvo a una sesión después de un tiempo. En este punto, honestamente solo estoy considerando hacer una copia de seguridad de todo, borrar el servidor y reinstalar sin un sistema de archivos cifrado. No guardo nada remotamente importante en él, así que no me preocupa demasiado el cifrado de mis archivos.

— Alex

El mantenedor / autor de eCryptfs en Ubuntu responde muy bien a los informes de errores. Si no puede encontrar una solución, probablemente valga la pena preguntarle o presentar un informe de error.

— Blujay

Puede intentar ejecutar el comando de sincronización entre sus comandos bash.

sync - flush file system buffers

¡Nunca he encontrado la necesidad de eso, pero he conocido al menos a una persona que lo escribió prácticamente como cada segundo comando! Debe haberse quemado mal en el pasado con disco lento.

Internet parece ser ligero en la discusión sobre el uso del synccomando. Aquí hay un enlace a una entrada manual muy breve para sync: http://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

syncgarantiza que los datos se escriban desde la memoria al dispositivo de disco. Los datos aún podrían estar en la memoria caché del dispositivo de disco y no escribirse en el disco si el dispositivo de disco en sí es lento o tiene un problema.

Estás ejecutando un servidor ubuntu. . . ¿Es esa una máquina en tu escritorio? ¿O está en una nube? O . . ¿algo más? Consulte aquí: /server/534627/what-does-the-sync-command-do sincronización lenta de la memoria al disco asociado con problemas de disco duro O tal vez con instancias más pequeñas de Amazon AWS.

— gaoithe
fuente

No estoy seguro de si syncserá de alguna utilidad; Descubrí que solo cd .mitigar el problema de todos modos. Hice un alias refpara ello (lo sé, guardar un personaje es un poco tonto) que tengo la costumbre de usar cada vez que vuelvo a una sesión anterior. En cuanto a lo que es el servidor, es mi antigua torre de escritorio (construí una nueva el año pasado) que ahora vive en la esquina de mi sala de estar ejecutando la distribución de Ubuntu, por lo que tengo acceso completo al hardware y poder sobre lo que está funcionando en eso.

— Alex

FWIW el problema se muestra con el comando ls, no con bash.

El hecho de que vea el archivo significa que todavía está allí. Nada está fuera de sincronización con nada más y ninguna cantidad de sincronización en ejecución le impedirá usar la única copia en caché de los datos relevantes del sistema de archivos. La sincronización solo hará que los datos se comprometan con el almacenamiento permanente, no cambiarán su visión.

¿Estás usando sesiones VIM? No conozco la sesión de VIM, nunca la usé yo mismo, pero imagino que tmux podría hacer que el administrador de la sesión de VI no se dé cuenta de que el archivo está cerrado y que se sigan los cambios.

— Johan
fuente