No se puede volver a montar / volver a solo lectura después de la actualización del paquete

Estoy usando Debian Stretch. Mi partición raíz está montada read-only. Solo cuando instalo o actualizo paquetes, se /vuelve a montar en read-write(usando apt hook) y luego se vuelve a montar en ro.

A veces, después de la actualización del paquete, no puedo /volver a montarlo en solo lectura:

mount -o remount,ro /
mount: / is busy

En versiones anteriores de Debian (Wheezy), podría enumerar los archivos abiertos que se han desvinculado con lsof:

 lsof +L1

o, más específicamente, archivos que evitan que se vuelvan /a montar en ro:

{ lsof +L1 ; lsof|sed -n '/SYSV/d; /DEL|(path /p;' ; } | grep -Ev '/(dev|home|tmp|var)'

Sin embargo, en Debian Stretch, lsof +L1no enumera ningún archivo.

No veo ningún cambio +|-Len man lsoflo que explicaría por qué dejó de funcionar.

¿Por qué lsof + L1 ya no enumera los archivos abiertos que se han desvinculado?

¿Cómo puedo enumerar aquellos archivos que impiden / se vuelven a montar en solo lectura?

ACTUALIZAR

He detenido todos los procesos que se pueden detener, y solo tengo inity gettysigo ejecutándose, pero aún no puedo volver /a montar ro.

¿Cómo puedo enumerar aquellos archivos que impiden / se vuelven a montar en solo lectura?

A) fuserse puede encontrar en el psmiscpaquete; Este es un caso de uso donde encuentro fuserbrillos y es más útil que lsof.

# fuser -v -m / 2>&1 | grep '[Ff]r.e'

Eso mostrará todos los procesos que tienen archivos abiertos en / para lectura (f) y escritura (F). Los archivos que evitarían / ​​volver a ser montados en solo lectura son aquellos que están abiertos para escritura (F).

Elimine los procesos que son un ejecutable que se ejecuta con archivos de directorio raíz abiertos para escritura .

# for fupid in $(fuser -v -m / 2>&1 | grep Fr.e | awk '{print $2}'); do kill $fupid; done

Eso está por encima de los systemdcomentarios con una advertencia. Si systemdes initasí fuserlo verá y hay otras consideraciones. Con la systemdejecución, puede (re) iniciar procesos a sus espaldas, incluso si acaban de ser identificados y eliminados fuser. systemdEs mucho más avanzado que el tradicional sysvinit.

B) La ACTUALIZACIÓN en la descripción indica que el sistema solo tiene ... inity gettysigue ejecutándose ...

Veo el comentario que dice que el sistema no está usando systemd, está usando init. En estiramiento, systemd es init . El comentario no decía explícitamente sysvinit, por lo que supongo que el sistema en cuestión puede estar usando el estiramiento predeterminado systemdpara init. O que otras personas que se topan con esta publicación, que están usando estiramientos systemd, encuentran útil esta parte.

Según el Wiki de Debian ,

El proceso de inicialización del sistema es manejado por el demonio init. En squeeze y versiones anteriores, ese demonio es proporcionado por el paquete sysvinit, y no se admiten alternativas. En wheezy , el demonio init predeterminado sigue siendosysvinit , pero hay disponible una "vista previa de tecnología" de systemd. En jessie y stretch , el sistema de inicio predeterminado essystemd , pero se admite el cambio a sysvinit.

Desde jessie, solo systemd es totalmente compatible; sysvinit es principalmente compatible, pero los paquetes Debian no son necesarios para proporcionar scripts de inicio sysvinit. runit también está empaquetado, pero no ha recibido el mismo nivel de prueba y soporte que los demás, y actualmente no es compatible como PID 1.

Con la systemdejecución, hay algunos pasos adicionales que se deben tomar para liberar / para que se pueda volver a montar sin problemas.

Es probable system.sliceque tenga archivos abiertos para systemd-journald.serviceo systemd-udevd.service(ambos tienen dependencias de socket). O, si se NetworkManagerestá ejecutando, puede reaparecer, lo dhclientque escribe arriendos en / var / ... (& / var / no siempre es su propio dispositivo), etc. fuserpodría encontrar y matar, dhclientpero lo NetworkManagerinicia de nuevo.

La moraleja es que muchas cosas están automatizadas que podrían 'querer' / (y aún más con systemd).

Sin duda, si es factible, el systemdequivalente del nivel de ejecución 1 se corresponde con rescue.target(y runlevel1.targetes un enlace simbólico a rescue.target).

1) Comience aislando el sistema para rescue.target

# systemctl isolate rescue.target

Debería solicitarle que ingrese la contraseña de root; siga las instrucciones en pantalla.

2) En el caparazón de rescate, averigua qué quiere /.

# systemctl show -p Wants /

Por lo general, es system.slice; para todo lo que quiera /. p.ej

# systemctl stop system.slice

3) En este punto, el remontaje no debe informar mount: / is busyy mount -o remount,ro / debe funcionar. Si no, verifique nuevamente con fuser.

4) FWIW; También he visto momentos en que umountfalla cuando / si otro dispositivo está montado en un subdirectorio de otro montaje, es decir, montajes anidados. Por ejemplo, umount /fallaría si / var / o / boot / está en otro dispositivo (y montado). Aunque mount -o remount,ro /aún debería funcionar en este caso.

lsblk Puede ser útil para visualizar monturas anidadas.

¿Por qué lsof + L1 ya no enumera los archivos abiertos que se han desvinculado?

Debido a que no están disponibles (sockets o la mayoría de los FIFOs y tuberías), ya no son archivos abiertos (el proceso padre cerró el descriptor de archivo) o (todavía) tienen un recuento de enlaces mayor que 1.

hombre lsof (8) detalles ...

+ | -L [l]

Esta opción habilita ('+') o deshabilita ('-') la lista de recuentos de enlaces de archivos, donde están disponibles, por ejemplo, no están disponibles para sockets, o la mayoría de FIFOs y tuberías.

Cuando se especifica + L sin un número siguiente, se enumerarán todos los recuentos de enlaces. Cuando se especifica -L (el valor predeterminado), no se enumerarán los recuentos de enlaces.

Cuando + L va seguido de un número, solo se enumerarán los archivos que tengan un enlace menor que ese número . (No puede seguir ningún número -L.) Una especificación del formulario '' + L1 '' seleccionará los archivos abiertos que se han desvinculado. Una especificación del formulario +aL1 <file_system>seleccionará archivos abiertos no vinculados en el sistema de archivos especificado.

¿Te has /procmontado?

Al parecer, siendo alguien que se encarga de /montar solo lectura la mayor parte del tiempo, me imagino que también podría optar por no montar procfs. Pero procfs es necesario para lsofencontrar archivos abiertos.

Los archivos abiertos por procesos son expuestos por el núcleo a través de enlaces simbólicos en procfs. Los directorios /proc/<pid>/fdcontienen un enlace simbólico para cada archivo abierto. El nombre de los enlaces simbólicos son los números de los descriptores de archivo, y la ruta a la que hace referencia el enlace simbólico es la ruta del archivo.

Los enlaces simbólicos colgantes aún permanecen en /proclos archivos abiertos que ya están eliminados. Y la ruta referenciada del archivo se renombra para terminar con "(eliminado)".

Lo que lsof +L1hace esencialmente no es diferente de una línea rápida como:

stat -c%N /proc/[0-9]*/fd/* | grep deleted

Por lo tanto, puede usar una línea similar para enumerar todos los archivos abiertos que pueden evitar que el sistema de archivos raíz se vuelva a montar (siempre que funcione /proc).

Sin embargo, si lo hizo / lo hizo /proc, las únicas otras causas en las que puedo pensar son errores ... De todos modos, para su información, en mi actual sistema Debian Stretch. lsof +L1Funciona como se esperaba.

bash# lsb_release -d
Description:    Debian GNU/Linux 9.5 (stretch)

bash# uname -a
Linux bwp-249-8 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux

bash# lsof -v
lsof version information:
    revision: 4.89
    [...]

Solo pude reproducir este problema una vez y lo resolví simplemente mountcon la opción -n .

Citando a man mount :

-n, --no-mtab
      Mount without writing in /etc/mtab.  This is necessary for example when /etc is on a read-only filesystem.

El mountprograma en sí mismo abriendo archivos para escribir en el sistema de archivos raíz me pareció una explicación plausible. Después de todo, mountescribe específicamente /etc/mtaby, a /etcmenudo, forma parte del sistema de archivos raíz. Sin embargo, no pude reproducirlo nuevamente en la misma máquina después de hacerlo una vez ...

¿Podría esto resolver tu problema?

Sin visibilidad en su sistema, es muy difícil decirle exactamente cuál es el problema. Los comentarios y las respuestas anteriores son buenos comienzos.

Dicho esto, volvería a través de la wiki de Debian que describe los requisitos previos para el montaje / solo lectura.

El enlace a la documentación está aquí: https://wiki.debian.org/ReadonlyRoot

El grande te acompañaré por aquí:

1 - hay ubicaciones específicas debajo / que deben leerse y escribirse. Según la documentación, se parece a esto:

sus dispositivos de bloque probablemente serán diferentes, dependiendo de la configuración de su pila de almacenamiento (particiones, lvm sin particiones, etc.) pero la idea principal es que necesita esos 4 puntos de montaje para tener su subsiguiente sistema de archivos montado para tener la opción de montaje RW.

2: hay una serie de archivos especiales en / etc que necesita para crear un enlace simbólico o implementar algún otro cambio (específicamente detallado en el artículo vinculado). Estos pueden o no aplicarse según las aplicaciones que esté ejecutando su servidor Linux. Es posible que algunos archivos ni siquiera existan en su máquina, pero incluí todo en los documentos. Tenga en cuenta que le recomiendo hacer estos cambios INCLUSO SI ha eliminado el pid del proceso. Estas son las rutas directamente desde el wiki de Debian:

• adjtime
• init.d / alsa-utils
• / etc / courier / shared / index
• los archivos de estado de cups, classes.conf, cupsd.conf, printers.conf subscriptions.conf
• /etc/lvm/lvm.conf
• mtab (que parece que trataste de abordar dando a mount la bandera -n)
• red / ejecución (usado por ifup e ifdown, en compresión. puede no aplicarse a estiramiento, ymmv)
• nologin
• resolv.conf
• ambos archivos passwd y shadow
• samba / dhcp.conf
• chupar
• udev

Una vez que haya verificado todo lo anterior y haya confirmado que se ajustan a las especificaciones de la wiki, lo siguiente que debe verificar es /etc/apt/apt.conf

DPkg {
// Auto re-mounting of a readonly /
Pre-Invoke { "mount -o remount,rw /"; };
Post-Invoke { "test ${NO_APT_REMOUNT:-no} = yes || mount -o remount,ro / || true"; };
}; 

según su error, lo último que puede verificar según la documentación proviene de lo siguiente:

"Después de una actualización de paquetes, es posible que se enfrente al problema de que Mount se niega a volver a montar el sistema de archivos que solo le dice" / está ocupado ". Esto se debe a que los archivos eliminados todavía los utiliza un proceso. Para averiguar qué procesos se utilizan eliminados los archivos usan la herramienta checkrestart (1) del paquete debian-goodies o usan el siguiente comando. A menudo se trata de demonios que usan bibliotecas actualizadas. Hay que reiniciarlos para que los archivos se publiquen ".

comando proporcionado en el documento:

{lsof +L1; lsof|sed -n '/SYSV/d; /DEL\|(path /p;'} |grep -Ev '/(dev|home|tmp|var)'

Sin conocer la configuración exacta del sistema de archivos, la partición y la configuración del dispositivo de almacenamiento, es difícil darle mucho más para seguir. Comenzaría por regresar y volver a verificar sus requisitos previos en la documentación (y se describe anteriormente).