Проблема при join ноды в куб кластер
(кстати на дебиане такой проблемы не встретил, только на убунте)
решение:
#troubleshooting #kubernetes
(кстати на дебиане такой проблемы не встретил, только на убунте)
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
Хорошая статья, которая показывает как правильно и красиво поступить в ситуации, когда нужно что-то откатить\удалить в ветке коммитов.
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
Очень глупая история произошла со мной на днях. Есть система автоматизации выкатки новых образов(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 переменные - имя задачи и ее номер.
Если ни тыкание на крестик, ни перезагрузка сервера не помогают дропнуть зависшую день-два-месяц назад задачу, то можно дропнуть ее через консоль (Manage Jenkins -> Script Console). И вам надо заполнить 2 переменные - имя задачи и ее номер.
Jenkins.instance.getItemByFullName("JOB_NAME")#jenkins #troubleshooting
.getBuildByNumber(JOB_ID)
.finish(
hudson.model.Result.ABORTED,
new java.io.IOException("Aborting build")
);
Убитый контейнер докера не запускается
Ошибка:
#docker #troubleshooting #networking
Ошибка:
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 и выполнении команды
Поможет доустановка пакетов:
#troubleshooting
При изменение репоса 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 правим
3. опционально разрешаем это для root:
в файле /etc/security/limits.d/core.conf
4. задаем поведение для демона, создающего дампы:
в файле /etc/sysctl.d/coredumps.conf
5. применение:
6. проверка:
в /var/lib/coredumps (или /var/tmp по-умолчанию) создастся coredump.
З.Ы. без каких либо настроек после установки пакета можно сразу управлять дампами через команду
#troubleshooting #coredump
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
Окна при этом не будут закрыты. Аналог команды для терминала:
#troubleshooting
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
Грабли! Грабли! Грабли! куда же без них...
Традиционно выкладываю свой опыт обновления тестового кластера на новую мажорную версию. Итак, прежде чем обновляться, читаем:
Тыц: https://github.com/kubernetes/kubernetes/issues/65863
и Тыц: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md
#kubernetes #troubleshooting
GitHub
failed to load Kubelet config file /var/lib/kubelet/config.yaml after kubelet update · Issue #65863 · kubernetes/kubernetes
Is this a BUG REPORT or FEATURE REQUEST?: Uncomment only one, leave it on its own line: /kind bug What happened: /var/lib/kubelet/config.yaml got removed after kubelet update. What you expected to ...
Получаем информацию о смонтированных rbd на нодах куба
Запускать на ноде куба. Этот скрипт полезен, если у вас дохлый мастер, иначе все это куда проще достается из апишки.
Результат:
т.е. отсюда можно узнать какому конкретно контейнеру какой конкретно image соответствует. Это полезно когда у вас динамический контроллер и сдохший мастер - чтобы забрать данные с запущенных подов.
#ceph #kubernetes #troubleshooting
Запускать на ноде куба. Этот скрипт полезен, если у вас дохлый мастер, иначе все это куда проще достается из апишки.
#!/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
Ошибка:
#troubleshooting #apt
Ошибка:
Err:1 http://archive.ubuntu.com/ubuntu xenial InReleaseНа самом деле проблема не о том, о чём написано в ошибке - проблема в записи в директорию /tmp.
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?)
#troubleshooting #apt
Jenkins heartbeat error
err:
В моем случае jenkins находится в k8s, катал его с помощью helm. В качестве решения в values.yaml:
#jenkins #kubernetes #helm #troubleshooting
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
#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
я хз че это было, но вы поймете когда вам это понадобится))
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
GitHub
moby/contrib/init/systemd/docker.socket at master · moby/moby
The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems - moby/moby
*бучий OVH
Иногда бывают ситуации когда не грузятся виртуалки. В VNC можно увидеть экран на котором есть фраза о начале загрузки с диска и на этом все виснет.
В качестве одного из решений - такое происходит когда у вас побилась ФС. тогда можно перезагрузиться в resque, и натравить утилиту fsck на ваш диск. в 50% случаев вам это поможет и после перезагрузки нода снова будет в строю. В других 50% вы получите ошибку ERROR в статусе openstack и тут можете даже не писать в ТП, они уже ничего не сделают - можно идти и смело переустанавливать ноду.
З.Ы. не сделают - потому что они жопорукие.
#ovh #troubleshooting
Иногда бывают ситуации когда не грузятся виртуалки. В VNC можно увидеть экран на котором есть фраза о начале загрузки с диска и на этом все виснет.
В качестве одного из решений - такое происходит когда у вас побилась ФС. тогда можно перезагрузиться в resque, и натравить утилиту fsck на ваш диск. в 50% случаев вам это поможет и после перезагрузки нода снова будет в строю. В других 50% вы получите ошибку ERROR в статусе openstack и тут можете даже не писать в ТП, они уже ничего не сделают - можно идти и смело переустанавливать ноду.
З.Ы. не сделают - потому что они жопорукие.
#ovh #troubleshooting
Ubuntu 18 и локальный dns
Столкнулись с очень веселым поведением сегодня на бубунточке. Эта красивая и без сомнения удобная ОС использует локальный резолвер dns из коробки. т.е. вместо стандартных записей dns серверов полученных по dhcp в /etc/resolv.conf будет помещена запись типа 127.0.53.1. Локально на этом адресе будет слушать systemd-resolver. Казалось бы ну ок, к чему это может привести..?
А вот к чему. Когда вы запускаете локально docker, он монтирует /etc/resolv.conf с хоста внутрь контейнера. Угадайте, работает ли внутри контейнера после этого dns резолв, когда обращаться надо в 127.0.53.1? Правильно, нихуа!
В качестве решения - отключаем напрочь эту очень удобную фичу:
Disable and stop the systemd-resolved service:
перезапускаем службу нетворк-манагера
#networking #dieubuntudie #troubleshooting
Столкнулись с очень веселым поведением сегодня на бубунточке. Эта красивая и без сомнения удобная ОС использует локальный резолвер dns из коробки. т.е. вместо стандартных записей dns серверов полученных по dhcp в /etc/resolv.conf будет помещена запись типа 127.0.53.1. Локально на этом адресе будет слушать systemd-resolver. Казалось бы ну ок, к чему это может привести..?
А вот к чему. Когда вы запускаете локально docker, он монтирует /etc/resolv.conf с хоста внутрь контейнера. Угадайте, работает ли внутри контейнера после этого dns резолв, когда обращаться надо в 127.0.53.1? Правильно, нихуа!
В качестве решения - отключаем напрочь эту очень удобную фичу:
Disable and stop the systemd-resolved service:
# systemctl disable systemd-resolved.serviceДобавляем в секцию [main] запись в файл /etc/NetworkManager/NetworkManager.conf
# systemctl stop systemd-resolved
dns=defaultDelete the symlink /etc/resolv.conf
rm /etc/resolv.conf
перезапускаем службу нетворк-манагера
service network-manager restartИсточник: https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu
#networking #dieubuntudie #troubleshooting
Ask Ubuntu
How to disable systemd-resolved in Ubuntu?
How can I disable systemd-resolved in Ubuntu 17.04?
Disabling it with systemctl disable didn't work, the service seems to be restarted (by Networkmanager?)
Disabling it with systemctl disable didn't work, the service seems to be restarted (by Networkmanager?)
puppet don't update user password
при запуске puppet agent с debug увидел такую проблему:
проблема, как пишут на форумах, действительно с пакетом ruby-shadow, но есть нюанс. Если у вас стоит устаревшая версия puppet, а сервер обновлен до stretch, то у вас проявится проблема с этим ruby-гемом. ruby стоит старый, а пакет приносит gem более свежий и такая комбинация как раз приводит к ошибке. В качестве решения - просто ставить более старую версию пакета.
#puppet #troubleshooting
при запуске puppet agent с debug увидел такую проблему:
Provider useradd does not support features manages_passwords; not managing attribute password
проблема, как пишут на форумах, действительно с пакетом ruby-shadow, но есть нюанс. Если у вас стоит устаревшая версия puppet, а сервер обновлен до stretch, то у вас проявится проблема с этим ruby-гемом. ruby стоит старый, а пакет приносит gem более свежий и такая комбинация как раз приводит к ошибке. В качестве решения - просто ставить более старую версию пакета.
echo "deb http://ftp.debian.org/debian jessie main contrib non-free" >> /etc/apt/sources.list.d/debian.list
apt update
apt install -y --force-yes ruby-shadow=2.3.4-2
puppet agent -t
#puppet #troubleshooting
Forwarded from Пятничный деплой
Шпаргалка по траблшутингу сети https://medium.com/@devopslearning/100-days-of-devops-day-62-useful-linux-command-for-network-troubleshooting-920430a2f75f #network #troubleshooting
Medium
100 Days of DevOps — Day 62-Useful Linux Command for Network Troubleshooting
Welcome to Day 62 of 100 Days of DevOps, Focus for today is useful Linux Command for Network Troubleshooting
Проблемы при переходе на buster
Сейчас только со стороны desktop. Пока список маленький, по мере выявления проблем буду добавлять
- slack desktop требует пакета libcurl3, но в buster он заменяется на libcurl4. При этом сам слак запускается и работает. В целом проблемы не вижу
- virtualbox-6.0 аналогично требует пакет libcurl3. Под buster vbox еще не собрали. как workaround - можно поставить из bionic.
#troubleshooting #debian10 #buster
Сейчас только со стороны desktop. Пока список маленький, по мере выявления проблем буду добавлять
- slack desktop требует пакета libcurl3, но в buster он заменяется на libcurl4. При этом сам слак запускается и работает. В целом проблемы не вижу
- virtualbox-6.0 аналогично требует пакет libcurl3. Под buster vbox еще не собрали. как workaround - можно поставить из bionic.
#troubleshooting #debian10 #buster
питон на маке поломался
после позавчерашнего обновления питона и еще каких-то пакетов (brew upgrade) столкнулся с ошибкой в ansible (питон скрипты просто падали):
решение нашел тут: https://stackoverflow.com/questions/58272830/python-crashing-on-macos-10-15-beta-19a582a-with-usr-lib-libcrypto-dylib
#troubleshooting #macos #python
после позавчерашнего обновления питона и еще каких-то пакетов (brew upgrade) столкнулся с ошибкой в ansible (питон скрипты просто падали):
Invalid dylib load. Clients should not load the unversioned libcrypto dylib as it does not have a stable ABI.
решение нашел тут: https://stackoverflow.com/questions/58272830/python-crashing-on-macos-10-15-beta-19a582a-with-usr-lib-libcrypto-dylib
brew install openssl
cd /usr/local/lib
sudo ln -s /usr/local/opt/openssl/lib/libssl.dylib libssl.dylib
sudo ln -s /usr/local/opt/openssl/lib/libcrypto.dylib libcrypto.dylib
#troubleshooting #macos #python