GNU/Linux >> Tutoriales Linux >  >> Linux

Cambio de permiso de /dev/shm después de reiniciar el nodo

La memoria compartida es una forma de estado compartido entre procesos. La memoria compartida, como su nombre lo indica, es un método para “compartir” datos entre procesos. Ambos procesos definen la misma área de memoria como "compartida", y luego pueden intercambiar información simplemente escribiendo en ella. Esto (solía ser, y todavía lo es un poco) más rápido que la alternativa de enviar mensajes basados ​​en redes o tuberías entre procesos.

Si ve la memoria como un medio para almacenar datos, un archivo en un sistema de archivos puede verse como memoria compartida (es decir, archivo compartido). Es difícil dar cuenta de la memoria compartida. ¿Pertenece a un proceso? ¿Ambas cosas? ¿Ninguno de los dos? Si sumamos ingenuamente la memoria que pertenece a múltiples procesos, groseramente "contamos en exceso".

Como su nombre lo indica, la memoria compartida (virtual) se refiere a la memoria virtual compartida por más de un proceso y luego puede ser utilizada por varios programas simultáneamente. Aunque la memoria virtual permite que los procesos tengan espacios de direcciones (virtuales) separados, hay momentos en los que necesita que los procesos compartan memoria. La memoria compartida (SHM) es otro método de comunicación entre procesos (IPC) mediante el cual varios procesos comparten una sola porción de memoria para comunicarse.

La memoria compartida proporciona la forma más rápida para que los procesos pasen grandes cantidades de datos entre sí. /dev/shm no es más que la implementación del concepto tradicional de memoria compartida. Es un medio eficiente de pasar datos entre programas. Un programa creará una parte de la memoria, a la que pueden acceder otros procesos (si están permitidos). Esto resultará en acelerar las cosas en Linux.

El problema

En cada reinicio del servidor, el permiso /dev/shm cambia:

$ ls -alrt /dev/ | grep shm
drwxr-xr-t. 2 root root 60 jul 6 11:14 shm 

Permiso original (1777):

# ls -ld /dev/shm
drwxrwxrwt. 2 root root 200 Aug 20 03:44 /dev/shm

Permiso existente (1754):

$ ls -alrt /dev/ | grep shm
drwxr-xr-t. 2 root root 60 jul 6 11:14 shm

La solución

La causa del problema es el paquete initscripts existente [initscripts-9.49.37-1.0.1.el7_3.1.x86_64].

Solución alternativa

Paso 1 :Enmascarar el servicio (rhel-import-state):

# systemctl mask rhel-import-state

Paso 2 :Comprobar el estado del servicio. Tendrá un aspecto similar al siguiente:

rhel-import-state.service
  Loaded: masked (/dev/null; bad) <<  Active: active (exited) since Fri 2017-07-21 18:28:05 EDT; 2 weeks 3 days ago
 Main PID: 600 (code=exited, status=0/SUCCESS)
  CGroup: /system.slice/rhel-import-state.service

Paso 3 :reinicie la máquina y confirme si el mismo problema vuelve a ocurrir o no.

Nota :Este es el plan de acción alternativo. Para una resolución permanente, actualice la versión del paquete initscripts a 9.49.39-1.0.1, que se incluye en la actualización 4 de CentOS/RHEL7.

Revertir los cambios

También puede revertir los cambios ejecutando el siguiente comando para desenmascarar el servicio enmascarado.

# systemctl unmask rhel-import-state.service
# systemctl status rhel-import-state.service


Linux
  1. ¿Cómo maneja Linux múltiples separadores de rutas consecutivas (/home////username///file)?

  2. Conflictos de Node.js:/sbin/node Vs /usr/bin/node?

  3. Cómo mapear dispositivos /dev/sdX y /dev/mapper/mpathY desde el dispositivo /dev/dm-Z

  4. ¿Qué es /dev/mem?

  5. ¿Cómo puedo cambiar la cantidad y el tamaño de los ramdisks de Linux (/dev/ram0 - /dev/ram15)?

¿Cuándo usar /dev/random Vs /dev/urandom?

¿Cómo codificar en base64 /dev/random o /dev/urandom?

¿Cuándo debo usar /dev/shm/ y cuándo debo usar /tmp/?

kernel:deshabilitar /dev/kmem y /dev/mem

¿Está mal vincular /dev/random a /dev/urandom en Linux?

¿Por qué se requieren < o > para usar /dev/tcp?