Mount LVM in rescue

Представим что у нас есть диск с LVM, который мы примонтировали к виртуалке или просто загрузились с ливки на железе. на нужном диске lvm, просто так примонтировать не удастся. Для начала надо просканировать все LVM диски группы и тома:

pvscan && vgscan && lvscan

смотрим результат:

lvs --all

активируем нужные тома или все сразу:

vgchange -a y [volgroup00]

смело монтируем:

mount /dev/mapper/vg_blah-blah /mnt

#lvm #disk #troubleshooting

partclone - отличная тулза для клонирования любых файловых систем (быстро и просто и может скипать плохие сектора).

#troubleshooting #disk

что-та сожрало все место на жестком диске!!!

Вы такие заходите на сервер, выполняете df -h и видите следующую картину:

/dev/sdb         49G   49G   0G  100% /var/log

Воу-воу, полегче думаете вы. Расчехляем пылесос и начинаем зачистку логов. Для начала следует выснить кто же поднасрал:

cd /var/log && du -hs ./* | grep G

Видим несколько файлов - 13G и 1G. Так. приехали. Уже что-то не так. окейси, вдруг там кто-то в корень логов насрал множеством файлов. ls -lash - ба. да файлов с папками всего ничего. ХММММ думаете вы. Ну, ок, посчитаем:

du -hs ./

20G

Но ведь df показывает 49!!! WTF!? Что это может значить, когда файлы по факту занимают куда меньше чем показывает общая занятость диска. Первая мысль - проверить размер диска и фс. вдруг кто-то что-то подкрутил. А вторая - куда более правильная - место занимают файлы, которых нет. Нет ничего что занимает, значит это и занимает, ага. Это значит, что мы столкнулись с ситуацией, когда файл с диска удалили, но процесс еще держит его открытым. проверим эту теорию:

# lsof | grep "/var/log" | grep deleted
filebeat   2211                root   13r      REG               8,16 32037162645         27 /var/log/haproxy.log.1 (deleted)
filebeat   2211  2212          root   13r      REG               8,16 32037162645         27 /var/log/haproxy.log.1 (deleted)
filebeat   2211  2213          root   13r      REG               8,16 32037162645         27 /var/log/haproxy.log.1 (deleted)
....

А, вот оно. Проблема в том, что при ротации лога, filebeat не отпускает старый файл. В данной ситуации достаточно перезапустить службу filebeat и волшебным образом место на жестком диске вернется обратно.

З.Ы. Вычитал тут полезный ключик для ncdu\du - ключ -x - который не будет обсчитывать вглубь примонтированные тома. так, например, если у вас смонтировано на /var, /var/log, итп какие-то тома (удаленные или локальные), запустив ncdu -x / вы получите информацию только по корню без смонтированных.

#disk #troubleshooting

Проблема при join ноды в куб кластер

(кстати на дебиане такой проблемы не встретил, только на убунте)

ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables does not exist

решение:

modprobe br_netfilter

#troubleshooting #kubernetes

git undoing operations

Хорошая статья, которая показывает как правильно и красиво поступить в ситуации, когда нужно что-то откатить\удалить в ветке коммитов.

https://sethrobertson.github.io/GitFixUm/fixup.html

#git #troubleshooting

Именование VM в облаках это важно

Очень глупая история произошла со мной на днях. Есть система автоматизации выкатки новых образов(images) в облака, в частности это azure. Для того чтобы задачи сборки не конфликтовали друг с другом, если запущены они в одно время, я добавил в имя виртуальной машины build_id, т.е. номер сборки. Через точку. Azure из имени VM составляет hostname. As is. В итоге получилось имя вида test-instance.123 - что в свою очередь очень напоминает нам домен второго уровня (company.com). Как оказалось на такое имя не весь софт реагирует адекватно и по понятным причинам такое имя не резолвится. В частности это не перенес collectd, что привело к невозможности его запуска. Замена точки на дефис решила эту глупую и простую проблему.

#troubleshooting

Jenkins kill zombie job

Если ни тыкание на крестик, ни перезагрузка сервера не помогают дропнуть зависшую день-два-месяц назад задачу, то можно дропнуть ее через консоль (Manage Jenkins -> Script Console). И вам надо заполнить 2 переменные - имя задачи и ее номер.

Jenkins.instance.getItemByFullName("JOB_NAME")
                .getBuildByNumber(JOB_ID)
                .finish(
                        hudson.model.Result.ABORTED,
                        new java.io.IOException("Aborting build")
                );

#jenkins #troubleshooting

Убитый контейнер докера не запускается

Ошибка:
endpoint with name XXXX already exists in network bridge.
Решение:
docker network disconnect --force bridge <Container ID or Endpoint ID or Container NAME>

Это не для тех, кто не умеет гуглить, а для того чтобы наоборот каждый раз не гуглить когда такое возникает=)

#docker #troubleshooting #networking

wheezy to stretch update

При изменение репоса wheezy -> stretch и выполнении команды apt-get update может вылезти ошибка связанная с отсутствием ключей.

W: There is no public key available for the following key IDs:

Поможет доустановка пакетов:

apt-get install debian-keyring debian-archive-keyring

#troubleshooting

Включаем coredump для ОС c systemd на борту

1. ставим пакет для управления - systemd-coredump

2. разрешаем дампить coredump процессам:
в файле /etc/systemd/system.conf правим

DefaultLimitCORE=infinity

3. опционально разрешаем это для root:
в файле /etc/security/limits.d/core.conf

root       hard        core        unlimited
root       soft        core        unlimited

4. задаем поведение для демона, создающего дампы:
в файле /etc/sysctl.d/coredumps.conf

kernel.core_pattern = /var/lib/coredumps/core-%e-sig%s-user%u-group%g-pid%p-time%t
kernel.core_uses_pid = 1
fs.suid_dumpable = 2

5. применение:

systemctl daemon-reexec или reboot

6. проверка:

kill -11 <PID>

в /var/lib/coredumps (или /var/tmp по-умолчанию) создастся coredump.

З.Ы. без каких либо настроек после установки пакета можно сразу управлять дампами через команду

coredumpctl list и coredumpctl dump

#troubleshooting #coredump