Je suis un peu déconcerté que l'intérieur d'un conteneur Docker lsof -i
ne donne aucune sortie.
Exemple (toutes les commandes / sorties de l'intérieur du conteneur):
[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 -
Veuillez également noter qu'aucun PID ou nom de programme n'est affiché par netstat
. fuser
donne également une sortie quelque peu confuse et est incapable de localiser également les PID.
Quelqu'un peut-il nous éclairer à ce sujet?
- Comment puis-je remplacer
lsof -i
(pour voir le nom du processus aussi!) - Pourquoi la sortie de est-elle également
netstat
paralysée?
NB: Le conteneur s'exécute avec "ExecDriver": "native-0.1"
, c'est la propre couche d'exécution de Docker, pas 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:
(Je ne suis pas obsédé par le Permission denied
, car cela donne des chiffres. Ce qui m'embrouille, c'est la liste vide de PID aprè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)
Il y a un peu plus de sortie pour l'utilisateur connecté, qui est également correctement identifié, mais c'est tout. Il est apparemment impossible de discerner de quel type ( lsof -i
limites aux prises Internet) se trouve un certain "objet".
sshd
lignes (également liées), dont certaines pourraient être des sockets TCP, comme TYPE
unknown
. Particulier. Ajout de la sortie à ma question.
strace -s 2000 -o lsof.log lsof -i
cela vous donnera probablement des informations supplémentaires sur ce qui est bloqué.
strace
lui - même soit limité dans le conteneur. De nouvelles choses passionnantes à apprendre. Merci d'avoir rebondi. Doit frapper le lit, cependant.
lsof
rapport? Le même?