АЕ
пробовал раскоментить был вот такое
global_filter = [ "a|.*/|" ]
Size: a a a
2019 September 06
J
global_filter закоментирован
Так проблема то в чем?
В том что диск чем-то занят или в том что фильтры его срезают?
В том что диск чем-то занят или в том что фильтры его срезают?
АЕ
уже выяснили что диск чем то занят. так как фильтры все разрешают.
АЕ
вот сейчас нулями забиваю его и отправлю в ребут для проверки
MI
3644a842047e034002504c391074836bd: 1 dependencies : (8, 16) ```нашел весь диск целиком из команды ```3644a842047e034002504c391074836bd: 1 dependencies : (8, 16)
ну то есть он где-то таки используется.
MI
по итогу я больно бью коллег и подрядные организации которые свои решения толкают через pip install в основную систему
Да! 👍
J
Тьфу.
Ну через Blktrace \ blkparse можно попробовать посмотреть чем занят диск
Ну через Blktrace \ blkparse можно попробовать посмотреть чем занят диск
АЕ
Коллеги как итог. Высянил что диск занят был multipath
Помогло следующее
1) multipath -ll and dmsetup ls --tree ище нужный mpath
2) multipath –f mpath
3) dmsetup remove mpath
Помогло следующее
1) multipath -ll and dmsetup ls --tree ище нужный mpath
2) multipath –f mpath
3) dmsetup remove mpath
J
Коллеги как итог. Высянил что диск занят был multipath
Помогло следующее
1) multipath -ll and dmsetup ls --tree ище нужный mpath
2) multipath –f mpath
3) dmsetup remove mpath
Помогло следующее
1) multipath -ll and dmsetup ls --tree ище нужный mpath
2) multipath –f mpath
3) dmsetup remove mpath
А тебе, вроде, вчера еще с утра говорили про него.
АЕ
Да только это как то упустил.
2019 September 07
AY
Коллеги как итог. Высянил что диск занят был multipath
Помогло следующее
1) multipath -ll and dmsetup ls --tree ище нужный mpath
2) multipath –f mpath
3) dmsetup remove mpath
Помогло следующее
1) multipath -ll and dmsetup ls --tree ище нужный mpath
2) multipath –f mpath
3) dmsetup remove mpath
что привело к такой ситуации ? у меня такое только при instance resize с LVM случается
вылечивается пока примерно так же
вылечивается пока примерно так же
2019 September 10
СБ
Привет!
Есть ли какой-нибудь автоматический способ мониторить работоспособность консолей novnc proxy? Сервис активен, http-часть работает, а консоли недоступны до рестарта сервиса. Ошибок в логах нет.
Есть ли какой-нибудь автоматический способ мониторить работоспособность консолей novnc proxy? Сервис активен, http-часть работает, а консоли недоступны до рестарта сервиса. Ошибок в логах нет.
J
Привет!
Есть ли какой-нибудь автоматический способ мониторить работоспособность консолей novnc proxy? Сервис активен, http-часть работает, а консоли недоступны до рестарта сервиса. Ошибок в логах нет.
Есть ли какой-нибудь автоматический способ мониторить работоспособность консолей novnc proxy? Сервис активен, http-часть работает, а консоли недоступны до рестарта сервиса. Ошибок в логах нет.
До рестарта novnc-proxy?
А ты выяснял почему?
А ты выяснял почему?
СБ
До рестарта novnc-proxy?
А ты выяснял почему?
А ты выяснял почему?
В логах спокойствие, службы живые, ошибок не видно
НС
В логах спокойствие, службы живые, ошибок не видно
все логи посмотрел? или только novnc proxy лог?
J
В логах спокойствие, службы живые, ошибок не видно
Дебаг включен?
Что значит недоступны? Окно консоли отрисовывается?
Ошибку какую-то показывает?
К машинам по vnc подключиться можешь внешним клиентом?
Что значит недоступны? Окно консоли отрисовывается?
Ошибку какую-то показывает?
К машинам по vnc подключиться можешь внешним клиентом?
A
народ, кто сталкивался с такой проблемой
qemu-system-x86_64: -vnc 0.0.0.0:56: Failed to start VNC server: Failed to bind socket: Address already in use
qemu-system-x86_64: -vnc 0.0.0.0:56: Failed to start VNC server: Failed to bind socket: Address already in use
A
возникает рандомно
A
закономерность никак отследить не могу
A
ubuntu 14, mitaka