Estoy algo desconcertado de que dentro de un contenedor Docker lsof -ino produzca ningún resultado.
Ejemplo (todos los comandos / resultados desde el interior del contenedor):
[1] root@ec016481cf5f:/# lsof -i
[1] root@ec016481cf5f:/# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
Tenga en cuenta también cómo no se muestra ningún PID o nombre de programa netstat. fusertambién da una salida algo confusa y tampoco puede identificar los PID.
¿Alguien puede aclarar esto?
- ¿Cómo puedo sustituir
lsof -i(para ver también el nombre del proceso ) - ¿Por qué la producción de
netstatlisiado también?
NB: el contenedor se ejecuta con "ExecDriver": "native-0.1", que es la capa de ejecución propia de Docker, no LXC.
[1] root@ec016481cf5f:/# fuser -a4n tcp 22
Cannot stat file /proc/1/fd/0: Permission denied
Cannot stat file /proc/1/fd/1: Permission denied
Cannot stat file /proc/1/fd/2: Permission denied
Cannot stat file /proc/1/fd/3: Permission denied
Cannot stat file /proc/1/fd/255: Permission denied
Cannot stat file /proc/6377/fd/0: Permission denied
Cannot stat file /proc/6377/fd/1: Permission denied
Cannot stat file /proc/6377/fd/2: Permission denied
Cannot stat file /proc/6377/fd/3: Permission denied
Cannot stat file /proc/6377/fd/4: Permission denied
22/tcp:
(No estoy obsesionado con el Permission denied, porque eso representa cifras. Lo que me confunde es la lista vacía de PID después 22/tcp).
# lsof|awk '$1 ~ /^sshd/ && $3 ~ /root/ {print}'
sshd 6377 root cwd unknown /proc/6377/cwd (readlink: Permission denied)
sshd 6377 root rtd unknown /proc/6377/root (readlink: Permission denied)
sshd 6377 root txt unknown /proc/6377/exe (readlink: Permission denied)
sshd 6377 root 0 unknown /proc/6377/fd/0 (readlink: Permission denied)
sshd 6377 root 1 unknown /proc/6377/fd/1 (readlink: Permission denied)
sshd 6377 root 2 unknown /proc/6377/fd/2 (readlink: Permission denied)
sshd 6377 root 3 unknown /proc/6377/fd/3 (readlink: Permission denied)
sshd 6377 root 4 unknown /proc/6377/fd/4 (readlink: Permission denied)
sshd 6442 root cwd unknown /proc/6442/cwd (readlink: Permission denied)
sshd 6442 root rtd unknown /proc/6442/root (readlink: Permission denied)
sshd 6442 root txt unknown /proc/6442/exe (readlink: Permission denied)
sshd 6442 root 0 unknown /proc/6442/fd/0 (readlink: Permission denied)
sshd 6442 root 1 unknown /proc/6442/fd/1 (readlink: Permission denied)
sshd 6442 root 2 unknown /proc/6442/fd/2 (readlink: Permission denied)
sshd 6442 root 3 unknown /proc/6442/fd/3 (readlink: Permission denied)
sshd 6442 root 4 unknown /proc/6442/fd/4 (readlink: Permission denied)
sshd 6442 root 5 unknown /proc/6442/fd/5 (readlink: Permission denied)
Hay más resultados para el usuario conectado, que también se identifica correctamente, pero eso es todo. Aparentemente es imposible discernir de qué tipo ( lsof -ilímites a los enchufes de Internet) es un cierto "objeto".
fuente
lsofinforme? ¿Lo mismo?sshdlíneas (también relacionadas), algunas de las cuales podrían ser sockets TCP, comoTYPEunknown. Peculiar. Anexando el resultado a mi pregunta.strace -s 2000 -o lsof.log lsof -i, es probable que le brinde información adicional sobre lo que se está bloqueando.straceesté limitado en el contenedor. Cosas nuevas y emocionantes para aprender. Gracias por rebotar idea. Sin embargo, debe golpear la cama.Respuestas:
(NOTA: no está claro en la pregunta de cómo el autor de la pregunta está entrando en el contenedor ventana acoplable que estoy. Asumiendo que
docker exec -it CONTAINER bashse utilizó.)Tuve este problema al usar una imagen de docker basada en la
centos:7versión de docker1.9.0y para superar esto, simplemente ejecuté:docker exec --privileged -it CONTAINER bashTenga en cuenta la inclusión de
--privileged.Mi comprensión ingenua de la razón por la que esto es necesario: parece que Docker hace un esfuerzo para que el contenedor sea más "seguro", como se documenta aquí .
fuente
Ja, la trama se complica. Si alguien tiene una mejor respuesta, escríbala y la aceptaré, si es aceptable. Pero aquí la razón aparente. Qué negligente de mi parte ignorar los archivos de registro en el host :
Por lo tanto, apaparmor parece ser el culpable, aunque tendré que descubrir cómo convencerlo para que permita esto sin comprometer la seguridad del host / contenedor o para ver si es posible sin comprometer la seguridad.
fuente
Otra posibilidad, esta vez con una configuración de seguridad más precisa: otorgue el privilegio SYS_PTRACE al contenedor acoplable:
fuente
lsofnecesitaCAP_SYS_PTRACE: es necesario leer/proc/*/stat. See ptrace (2)También he encontrado este problema. El problema se fue después de que deshabilité
apparmorendocker:URL de referencia: https://help.ubuntu.com/community/AppArmor
fuente
aa-complainhace o alguna documentación que respalde esta solución).apparmor, simplemente busqué en Google y encontré la manera de desactivarlo. En otras palabras, no sé por qué funciona o por qué no funcionó. Mi sistema operativo host es Ubuntu 14.04, así que busqué "ubuntu apparmor" y encontré help.ubuntu.com/community/AppArmor . Espero que esto sea útil para ti.sudo aa-complain /etc/apparmor.d/docker. Básicamente, desactiva la armadura de la aplicación para el proceso de Docker, lo que significa que Docker puede leer cualquier archivo en el sistema. Anteriormente, solo podía funcionar con archivos permitidos en el perfil. Una mejor solución podría ser cambiar las reglas de armadura de la aplicación que permitirían el acceso a los archivos / proc / pid / fd.