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

перезапуск гнома

alt+F2 -> ввести букву r -> нажать enter

Окна при этом не будут закрыты. Аналог команды для терминала:

gnome-shell --replace

#troubleshooting

Kubernetes 1.10.x -> 1.11.x

Грабли! Грабли! Грабли! куда же без них...

Традиционно выкладываю свой опыт обновления тестового кластера на новую мажорную версию. Итак, прежде чем обновляться, читаем:

Тыц: https://github.com/kubernetes/kubernetes/issues/65863
и Тыц: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md

#kubernetes #troubleshooting

Получаем информацию о смонтированных rbd на нодах куба

Запускать на ноде куба. Этот скрипт полезен, если у вас дохлый мастер, иначе все это куда проще достается из апишки.

#!/bin/bash

IFS=$'\n'

for i in $(docker ps); do
  ID=$(echo $i | awk '{print $1}');
  for j in $(docker inspect $ID | grep "volumes/kubernetes.io~rbd"|grep -v "Source"); do
    NAME=$(docker inspect $ID | grep "Hostname\"")
    external_mpath=$(echo $j | awk -F\: '{print $1}' | grep -o '/var/lib.*')
    internal_mpath=$(echo $j | awk -F\: '{print $2}')
    rbd=$(mount | grep $external_mpath | awk '{print $1}')
    dnumber=$(echo $rbd | egrep -o "[0-9]+")
    image=$(cat /sys/bus/rbd/devices/${dnumber}/name)
    echo ""
    echo "name: $NAME"
    echo "rbd: $rbd"
    echo "mount path: $internal_mpath"
    echo "image: $image"
  done
done

Результат:

name:             "Hostname": "mongodb-database-865cfb8d6f-lgfnl",
rbd: /dev/rbd8
mount path: /data/db",
image: kubernetes-dynamic-pvc-af3f3636-635d-11e8-9801-0a580af4013f

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

#ceph #kubernetes #troubleshooting

apt update error

Ошибка:

Err:1 http://archive.ubuntu.com/ubuntu xenial InRelease
Couldn't create tempfiles for splitting up /var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_xenial_InRelease
Could not execute 'apt-key' to verify signature (is gnupg installed?)

На самом деле проблема не о том, о чём написано в ошибке - проблема в записи в директорию /tmp.

#troubleshooting #apt

Jenkins heartbeat error

err:

wrapper script does not seem to be touching the log file in xxxxx
(JENKINS-48300: if on a laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=300)

В моем случае jenkins находится в k8s, катал его с помощью helm. В качестве решения в values.yaml:

Master:
    JavaOpts: "-Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=3600"

#jenkins #kubernetes #helm #troubleshooting

вчера ночью боролся с set_fact в ansible. присваиваю переменной значение, а при обращении к переменной она undefined. Проблема крылась в пробелах слева и справа от знака равно. Убрал пробелы и все стало чётенько...

#ansible #troubleshooting #yaml

Нападение без объявления войны

я хз че это было, но вы поймете когда вам это понадобится))

https://github.com/moby/moby/blob/master/contrib/init/systemd/docker.socket

(Ну а так, ошибка такая: docker.service: Failed to schedule restart job: Unit docker.socket not found.)

#docker #troubleshooting

*бучий OVH

Иногда бывают ситуации когда не грузятся виртуалки. В VNC можно увидеть экран на котором есть фраза о начале загрузки с диска и на этом все виснет.

В качестве одного из решений - такое происходит когда у вас побилась ФС. тогда можно перезагрузиться в resque, и натравить утилиту fsck на ваш диск. в 50% случаев вам это поможет и после перезагрузки нода снова будет в строю. В других 50% вы получите ошибку ERROR в статусе openstack и тут можете даже не писать в ТП, они уже ничего не сделают - можно идти и смело переустанавливать ноду.

З.Ы. не сделают - потому что они жопорукие.

#ovh #troubleshooting