Сеть / Ступень 5 из 14 · шаг 8 из 9

Порты: запустить службу app

~20 мин

Не запущена Запускается обычно ~20 с

Ситуация

Веб-служба app не работает: systemctl status app показывает failed. Служба должна отвечать на http://localhost:8080/ — на этот адрес настроены её клиенты.

Задача

Служба app активна и отвечает на http://localhost:8080/ кодом 200.
То, что мешало app, остановлено и не запустится снова после перезагрузки машины.

Порт app не меняй: клиенты ждут её на 8080.

Нужные инструменты уже установлены. Интернета на машине нет.

Цели лабы

0 из 3

То, что мешало app, остановлено и не запустится после перезагрузки — ещё не проверялась
Служба app активна — ещё не проверялась
На http://localhost:8080/ кодом 200 отвечает служба app — ещё не проверялась

Подсказки

открыто 0 из 3 · открываются по одной

Подсказка 1

Показать решение после 3 неудачных проверок

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

Сеть · подобрано по лабе

ss — сокеты и порты

Шпаргалка

$_ — вставить в терминал

ss -tlnp слушающие порты + кто
ss -tnp активные соединения
ss -tulnp TCP+UDP слушающие
ss -tlnp 'sport = :80' кто на 80
ss -tan state close-wait утечка сокетов?
ss -s статистика

Мнемоника частого набора -tlnp: tcp listening numeric process. -n важен на медленных сетях: без него ss пытается резолвить каждый адрес в имя, и вывод заметно тормозит. -p требует root, чтобы показать процессы других пользователей — без sudo увидишь только свои.

Команды

bash

ss -tlnp                          # слушающие TCP-порты + процессы
ss -ulnp                          # слушающие UDP-порты
ss -tnp                           # установленные TCP-соединения
ss -tanp                          # все TCP: и слушающие, и установленные
ss -s                             # сводка: сколько всего сокетов по типам
ss -tnp state established         # только установленные
ss -tnp state time-wait          # «зависшие» в TIME-WAIT
ss -tlnp '( sport = :80 or sport = :443 )'   # кто слушает 80/443
ss -tnp dst 10.0.0.5             # соединения к конкретному хосту
ss -tnp 'dport = :5432'          # соединения к порту postgres
ss -tnp dst 10.0.0.0/24          # к целой подсети
ss -tonp                          # с таймерами keepalive/retransmit
ss -tnp | wc -l                   # сколько активных TCP-соединений (грубо)

Состояния и фильтры

Фильтр по состоянию TCP — state <имя> (или state connected/listening):

bash

ss -tan state established         # рабочие соединения
ss -tan state syn-sent            # клиент ждёт ответа (висит коннект?)
ss -tan state close-wait          # приложение не закрывает сокеты (утечка fd!)
ss -tan state time-wait | wc -l   # много TIME-WAIT — частые короткие коннекты

Адресные фильтры комбинируются (and/or): src/dst (адрес), sport/dport (порт).

bash

ss -tnp 'dst 10.0.0.5 and dport = :443'
ss -tnp 'sport >= :1024'         # эфемерные исходящие порты

«Address already in use» при старте службы

Порт уже занят. Найди кем и останови/смени порт:

bash

ss -tlnp 'sport = :8000'         # users:(("python",pid=1234,fd=3))

Служба запущена, но снаружи недоступна

Слушает ли вообще: ss -tlnp | grep :PORT.
На 127.0.0.1 вместо 0.0.0.0/*? Тогда только локально — поправь bind в конфиге.
Порт открыт в файрволе? (nft list ruleset / ufw status — см. firewall).

Растёт число сокетов в CLOSE-WAIT

Приложение не закрывает соединения (утечка дескрипторов) — рано или поздно упрётся в ulimit. ss -tanp state close-wait покажет виновный процесс.

Много TIME-WAIT

Норма при большом числе коротких клиентских соединений; обычно не проблема. Лечится keep-alive/пулом соединений на стороне приложения, не тюнингом ядра наобум.

Непонятно, что за процесс держит соединение

ss -tnp покажет users:(("nginx",pid=1234,...)). Глубже — lsof.