Как определить какой процесс постоянно создает veth интерфейсы?

Question

[Михаил]

Имеется Gentoo Linux
Используется для разработки, поэтому в системе имеются виртуалки, такие как docker, lxc/lxd, virtualbox (и может быть что-то забыл).

Обнаружил следующую историю в логах:

Sep  4 08:54:25 whitewolf kernel: br-c322839fbe42: port 1(veth899b5bb) entered disabled state
Sep  4 08:54:25 whitewolf kernel: veth407912a: renamed from eth0
Sep  4 08:54:25 whitewolf kernel: br-c322839fbe42: port 1(veth899b5bb) entered disabled state
Sep  4 08:54:25 whitewolf kernel: device veth899b5bb left promiscuous mode
Sep  4 08:54:25 whitewolf kernel: br-c322839fbe42: port 1(veth899b5bb) entered disabled state
Sep  4 08:54:25 whitewolf kernel: br-c322839fbe42: port 1(veth0c59a27) entered blocking state
Sep  4 08:54:25 whitewolf kernel: br-c322839fbe42: port 1(veth0c59a27) entered disabled state
Sep  4 08:54:25 whitewolf kernel: device veth0c59a27 entered promiscuous mode
Sep  4 08:54:25 whitewolf kernel: br-c322839fbe42: port 1(veth0c59a27) entered blocking state
Sep  4 08:54:25 whitewolf kernel: br-c322839fbe42: port 1(veth0c59a27) entered forwarding state
Sep  4 08:54:25 whitewolf kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth0c59a27: link becomes ready
Sep  4 08:54:26 whitewolf kernel: br-c322839fbe42: port 1(veth0c59a27) entered disabled state
Sep  4 08:54:26 whitewolf kernel: eth0: renamed from veth9b42903
Sep  4 08:54:26 whitewolf kernel: br-c322839fbe42: port 1(veth0c59a27) entered blocking state
Sep  4 08:54:26 whitewolf kernel: br-c322839fbe42: port 1(veth0c59a27) entered forwarding state

Подобный фрагмент (каждый раз с разным veth***) повторяется примерно каждые 21 секунду.

Смотрю ip link:

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 18:31:bf:2c:78:8a brd ff:ff:ff:ff:ff:ff
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:51:e9:4f:bf brd ff:ff:ff:ff:ff:ff
4: br-c322839fbe42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:09:79:c1:94 brd ff:ff:ff:ff:ff:ff
7: lxdbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:16:3e:21:74:72 brd ff:ff:ff:ff:ff:ff
289: vethd10c351@if288: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c322839fbe42 state UP mode DEFAULT group default 
    link/ether 0e:e8:6f:51:c0:d9 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Через некоторое время:

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 18:31:bf:2c:78:8a brd ff:ff:ff:ff:ff:ff
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:51:e9:4f:bf brd ff:ff:ff:ff:ff:ff
4: br-c322839fbe42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:09:79:c1:94 brd ff:ff:ff:ff:ff:ff
7: lxdbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:16:3e:21:74:72 brd ff:ff:ff:ff:ff:ff
379: veth5522698@if378: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c322839fbe42 state UP mode DEFAULT group default 
    link/ether c6:75:3d:44:f2:36 brd ff:ff:ff:ff:ff:ff link-netnsid 0

То есть был 289-ый интерфейс, он исчез, появился 379. Если отслеживать с меньшим шагом - то видно как номер интерфейса нарастает с шагом 2: 379, 381, 383 и т.д. Насколько я понимаю, некий процесс создает и удаляет пары интерфейсов veth. Но что с этим делать дальше я не понимаю.

Как можно отследить кто занимается этой фигней?
Еще я не очень понимаю что есть интерфейс br-c322839fbe42. Как отследить кто к нему причастен?

Comments

[Дмитрий]

может какой то из контейнеров падает-поднимается-снова падает?

[planc]

init скрипты сервисов virtualbox и lxd друг с другом воюют скорее всего
убери их из автозапуска и стартуй в ручную, когда они нужны

[Михаил]

Дмитрий, как выяснилось - да. Один из контейнеров докера так фортелил.

[Михаил]

planc, нет, эти двое оказались не при чем. Проблема торчала из одного из контейнеров докера.

Answer 1

[meDveD_spb]

Проблема то есть или только логи смущают?
это нормальное поведение програмных интерфейсов, запуск, миграция вм/контейнеров/lxc с сетевыми интерфейсам.

Comments

[Михаил]

Это пока единственная аномалия, которую а нашел. А так проблема есть - компьютер периодически неспровоцированно перезагружается.

[meDveD_spb]

Михаил,
причин может быть несколько, и они не связаны с этим логом.
может быть с памятью связано, как и из-за неправильного взаимодействия между вирт парком, так и неисправностью самой плашки.

whitewolf kernel:

это от какой ВМ?

В чем причина такого зоопарка на одной машине, да ещё и генте?

[Михаил]

meDveD_spb, это хост. Спасибо за подсказку - это все-таки был один из контейнеров докера. Остановка dockerd привела к исчезновению veth, затем перезапустил и нашел глючный контейнер (это была kafka). Самое интересное, что это переживало перезагрузку, видимо благодаря docker-compose.

Насчет перезагрузок - буду наблюдать после убиения контейнера. Если будут продложаться - буду искать дальше.