# Поиск причины ошибки по логам
В процессе тестирования могут возникать ситуации, когда мы получаем неизвестные ошибки(1111) либо совершенно неинформативные. Рассмотрим поиск причины ошибки на следующем примере:
Получили ошибку в интерфейсе: `Error 3004, Unavailable`.
Попробуем выяснить первопричину ошибки, для этого:
1. Открываем консоль разработчика, вкладка "Network", смотрим, что за ошибка.
Видим Request URL, запрос в контейнере`updater`:
```bash=
https://172.31.226.18/api/updater/v3/update_status
```
2. Идём смотреть логи. Подключаемся к нашему тестовому стенду по ssh. Посмотрим точное название контейнера (если не знаем). Для этого можно использовать команду с гибкой настройкой вывода контейнеров, в результате которой получим только ID контейнера и его имя:
```bash=
docker ps --format "{{.ID}}: {{.Names}}"
```
:::info
Чтобы вывести список контейнеров с полной информацией, можно воспользоваться командой:
```bash=
docker ps
```
:::
3. Проваливаемся внутрь контейнера:
```bash=
docker exec -it dci_updater_1 bash
```
Логи некоторых контейнеров пишутся в var/log/*.log. Если сложно определить, в какой именно файл пишется ошибка, можно получить список записей из всех файлов следующей командой:
```bash=
tail -f /var/log/*.log
```
* Команда `tail` - выводит последние 10 строк файла.
* Флаг `-f` не завершает чтение по достижению конца файла, а ожидает появление новых записей, что удобно при одновременном воспроизведении ошибки и мониторинга логов.
* Если использовать команду после возникновения ошибки - это не поможет, т.к. инфа может быть выше 10 строк.
:::info
:WARNING: Если известно, что именно мы хотим увидеть в логах, можно использовать grep вместе с tail, например:
```bash=
"tail -f /var/log/*.log | grep "Connection error""
```
:::
Не все логи хранятся внутри контейнеров, некоторые пишутся напрямую в stdout. Чтобы посмотреть их, нужно выйти из контейнера и ввести команду:
```bash=
docker logs -f <название контейнера>
```
Чтобы остановить получение новых логов, нажать комбинацию клавиш `cntrl+C`.
4. Смотрим логи и видим такую запись:
```bash=
2022-11-01 10:40:53.766 [pid=13] WARNING [name=P/updater_v3/writer] Service process exited with bad return code (127)!
```
:::info
:warning: Код 127! - как правило, это означает:
* команда не найдена
* или команда найдена, но библиотека, требуемая командой, НЕ найдена
:::
5. Смотрим по логам выше - ищем, какой процесс был запущен, находим его:
6. Идем в контейнер и пробуем запустить этот процесс руками:
```bash=
/opt/ispsystem/updater/bin/updater --mode writer --port 3200 --address 127.0.0.1
```
В данном случае был получен ответ, что нет нужной библиотеки, к которой идет запрос:
```bash=
libc++.so.1 => not found
```
7. Тогда можем посмотреть, какие библиотеки использует сервис командой:
```bash=
ldd /opt/ispsystem/updater/bin/updater
```
:::success
`ldd` - команда, предназначенная для вызова одноименной утилиты, осуществляющей вывод списка разделяемых библиотек, используемых исполняемыми файлами или разделяемыми библиотеками.
:::
Получаем ответ:
```bash=
linux-vdso.so.1 (0x00007ffda91e2000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f2322950000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f232274c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f232252c000)
librt.so.1 => /lib64/librt.so.1 (0x00007f2322324000)
libc++.so.1 => not found
libc++abi.so.1 => not found
libm.so.6 => /lib64/libm.so.6 (0x00007f2321fa2000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2321d8a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f23219c5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2322b79000)
```
Видим, что библиотеки `libc++.so.1` и `libc++abi.so.1`- не найдены.
**Ура! Мы нашли причину ошибки.**
Идем к разработчику, чтобы поправил. :handshake:
Sign in with Wallet
Connect another wallet