Я несколько озадачен тем, что внутри контейнера Docker lsof -iничего не получается.
Пример (все команды / вывод изнутри контейнера):
[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 -
Также обратите внимание, что PID или название программы не отображаются netstat. fuserтакже дает несколько запутанный вывод и не может точно определить PID.
Кто-нибудь может пролить свет на это?
- Как я могу заменить
lsof -i(чтобы увидеть название процесса !) - Почему вывод
netstatкалекой так же?
NB . Контейнер работает с "ExecDriver": "native-0.1"собственным уровнем выполнения Докера, а не с 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:
(Я не одержим Permission denied, потому что эти цифры. Меня смущает пустой список PID после 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)
Еще есть вывод для подключенного пользователя, который также правильно идентифицирован, но это все. По-видимому, невозможно определить, к какому типу ( lsof -iограничениям интернет-сокетов) относится определенный «объект».
linux
docker
libcontainer
0xC0000022L
источник
источник
lsofотчет? Такой же?sshdсвязанных) строк, некоторые из которых могут быть сокетами TCP, какTYPEunknown. Свой. Добавление вывода к моему вопросу.strace -s 2000 -o lsof.log lsof -iего, скорее всего, вы получите дополнительную информацию о том, что блокируется.straceсам ограничен в контейнере. Захватывающие новые вещи, чтобы учиться. Спасибо за прыгающую идею. Должен врезаться в кровать, хотя.Ответы:
(ПРИМЕЧАНИЕ: неясно в вопросе, как запрашивающая сторона входит в контейнер докера. Я предполагаю, что
docker exec -it CONTAINER bashона использовалась.)У меня была эта проблема при использовании образа докера, основанного на
centos:7версии докера,1.9.0и чтобы преодолеть это, я просто запустил:docker exec --privileged -it CONTAINER bashОбратите внимание на включение
--privileged.Мое наивное понимание причины, по которой это необходимо: кажется, что докер прилагает усилия, чтобы сделать контейнер более «безопасным», как описано здесь .
источник
Ха, сюжет утолщается. Если у кого-то есть лучший ответ, пожалуйста, напишите его, и я приму его, если это приемлемо. Но тут очевидная причина. Как небрежно с моей стороны игнорировать файлы журналов на хосте :
Таким образом, apparmor, по-видимому, является виновником, хотя мне придется выяснить, как убедить его в том, что это разрешается без ущерба для безопасности хоста / контейнера или чтобы увидеть, возможно ли это вообще без ущерба для безопасности.
источник
Еще одна возможность, на этот раз с более тонкой настройкой безопасности: дать привилегию SYS_PTRACE контейнеру Docker:
источник
lsofнужноCAP_SYS_PTRACE: обязательно читать/proc/*/stat. См. Ptrace (2)Я тоже нашел эту проблему. Проблема ушла после того, как я отключил
apparmorнаdocker:URL ссылки: https://help.ubuntu.com/community/AppArmor
источник
aa-complainделает, или некоторую документацию, которая поддерживает это решение).apparmor, я просто погуглил и нашел способ отключить его. Другими словами, я не знаю, почему это работает или почему это не работает. Мой хост OS Ubuntu 14.04, поэтому я искал "ubuntu apparmor" и нашел help.ubuntu.com/community/AppArmor . Я надеюсь, что это будет полезно для вас.sudo aa-complain /etc/apparmor.d/docker. В основном это отключает броню приложения для процесса докера, что означает, что докер может читать любой файл в системе. Ранее он мог работать только с файлами, которые были разрешены в профиле. Лучшим решением может быть изменение правил брони приложения, которые позволят доступ к файлам / proc / pid / fd.