LINUX.ORG.RU
ФорумAdmin

Непонятное поведение юнита systemd. Прошу подсказки, куда копать.

 ,


2

1

Всем доброго времени суток. Такой вопрос: есть написанная мною программа (утилита с веб мордой, которая слушает на заданном адресе и порту и отвечает на http-запросы). Запускается, работает нормально и даже как задумано :)

Написал unit файл (hammer.service, он ниже вместе с логами), чтобы запускать с помощью systemd, положил в /etc/systemd/system. Сделал sudo systemctl daemon-reload.

Далее по команде sudo systemctl start hammer сервис запускается и работает нормально, т.е. видится в моей сети по 10.0.0.10:4242, отвечает на запросы и пр. systemctl status и systemctl stop также делают то, что должны. Но если перегрузить машину, сервис не стартует, ругаясь на «listen tcp 10.0.0.10:4242: bind: cannot assign requested address»

При этом если сразу после загрузки сделать sudo systemctl start hammer, то сервис стартует без проблем и работает.

Ниже юнит-файл и лог journalctl (как раз система запустилась, сервис не стартанул и я его стартую «руками»).

Прошу подсказать, если я пропустил что-то очевидное. В юнит-файле пробовал After=network.target или (как в логах ниже) After=netwotrk-online.target. Также пробовал Require=(оба варианта). Результат одинаковый.

Как я понимаю, After=netwotrk-online.target означает, что мой сервис должен стартовать после того, как сеть гарантированно поднялась.

В какую сторону копать? Какие есть идеи?

А теперь логи в студию…

cat /etc/systemd/system/hammer.service

[Unit]
Description=Hammer Systemd Assistant
After=network-online.target

[Service]
ExecStart=/usr/local/bin/hammer -serve -ip 10.0.0.10 -port 4242
Type=simple

[Install]
WantedBy=multi-user.target

journalctl -u hammer

-- Logs begin at Wed 2020-10-28 01:11:08 MSK, end at Wed 2020-10-28 01:17:56 MSK. --
окт 28 01:11:13 raspberry systemd[1]: Started Hammer Systemd Assistant.
окт 28 01:11:13 raspberry hammer[417]: Using /usr/local/etc/hammer.conf config file
окт 28 01:11:14 raspberry hammer[417]: listen tcp 10.0.0.10:4242: bind: cannot assign requested address
окт 28 01:11:14 raspberry systemd[1]: hammer.service: Main process exited, code=exited, status=1/FAILURE
окт 28 01:11:14 raspberry systemd[1]: hammer.service: Failed with result 'exit-code'.
окт 28 01:12:44 raspberry systemd[1]: Started Hammer Systemd Assistant.
окт 28 01:12:44 raspberry hammer[758]: Using /usr/local/etc/hammer.conf config file

Во избежание сомнений про IP адрес и пр.:

ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.10  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::a8d9:c5d0:55ab:40fc  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:4a:c7:a3  txqueuelen 1000  (Ethernet)
        RX packets 6860  bytes 935445 (913.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9553  bytes 1092106 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 145  bytes 57849 (56.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 145  bytes 57849 (56.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

route

route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router          0.0.0.0         UG    202    0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     202    0        0 eth0

Ответ на: комментарий от anonymous

Когда добавляешь новый юнит и делаешь systemctl daemon-reload он по умолчанию enabled у меня :)

И разумеется он добавился, я ж лог journalctl не зря показываю. В нем видно, что при старте системы сервис пытался запуститься, бинарник упал и вернул ошибку. После чего я его через минуту запустил по systemctl start.

paddlewan ()
Ответ на: комментарий от paddlewan

Судя по названию интерфейса вы используете ifupdown или типа того, соответственно, если я ничего не путаю, нужно врубить ifup-wait-all-auto.service (это для Debian 10, в других дистрибутивах может отличаться), чтобы network-online.target ожидал поднятие сети.

NeOlip ★★ ()
Последнее исправление: NeOlip (всего исправлений: 1)
Ответ на: комментарий от NeOlip

Не проверил пока, но очень похоже, что ответ в точку! В числе того, что хочет network-online.target этого сервиса не было. Посмотрел, куда он ведет, там скрипт, который делает что нужно. Проверю с утра.

Спасибо за наводку. Похоже, я недогуглил самую малость. Хотя честно говоря, не особо охота разбираться в деталях работы systemd :)

paddlewan ()

не совсем по теме, но тут можно использовать сокет-активацию. Т.е. systemd само создаёт сокет, слушающий порт 4242, и пробрасывает его дескриптор в твой сервис. Тогда точно не будет никаких проблем с ожиданием сети, т.к. сервис будет запускаться, только когда кто-то постучится на этот порт

Lrrr ()

В какую сторону копать? Какие есть идеи?

Конечно, есть.

Но если перегрузить машину, сервис не стартует, ругаясь на «listen tcp 10.0.0.10:4242: bind: cannot assign requested address»

Скорее всего, это значит, что твой сервис запустился до того, как этот адрес появился на одном из интерфейсов. Без специального флага нельзя забиндить сокет на адрес, которого не существует в системе.

При этом если сразу после загрузки сделать sudo systemctl start hammer, то сервис стартует без проблем и работает.

Логично. Сеть-то уже поднята.

Прошу подсказать, если я пропустил что-то очевидное. В юнит-файле пробовал After=network.target или (как в логах ниже) After=netwotrk-online.target. Также пробовал Require=(оба варианта). Результат одинаковый.

Как я понимаю, After=netwotrk-online.target означает, что мой сервис должен стартовать после того, как сеть гарантированно поднялась.

Да, но нет. network.target означает «сетевой менеджер запустился». Если твой сетевой менеджер назначает адреса асинхронно, то достижение этой цели ничего не значит.

network-online.target — это ближе к тому, что ты хочешь, но этот таргет магическим образом не работает. Для него нужна поддержка со стороны сетевого менеджера. Чем у тебя в системе управляется сеть?

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Привет. Спасибо за участие в теме и конструктив. Только сейчас дошли руки до этого вопроса.

Докладываю.

ifup-wait-all-auto.service - это не то, что было нужно :(

Дистрибутив у меня Raspberry OS (который бывший Raspbian). Это Debian-based история специально для Raspberry Pi, но с приколами.

Как выяснилось, сеть управляется dhcpcd. Он стучится в роутер, получает адрес и конфигурирует сетевой интерфейс и маршрут по умолчанию. Если я правильно понимаю, то это отвечает на вопрос, чем управляется сеть…

systemctl status dhcpcd

● dhcpcd.service - dhcpcd on all interfaces
   Loaded: loaded (/lib/systemd/system/dhcpcd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-10-28 05:17:13 MSK; 9h ago
  Process: 430 ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -b (code=exited, status=0/SUCCESS)
 Main PID: 491 (dhcpcd)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/dhcpcd.service
           ├─491 /sbin/dhcpcd -q -b
           └─593 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -Dnl80211,wext

окт 28 05:17:19 raspberry dhcpcd[491]: DUID 00:01:00:01:25:1e:c3:4f:dc:a6:32:4a:c7:a4
окт 28 05:17:19 raspberry dhcpcd[491]: eth0: IAID 32:4a:c7:a3
окт 28 05:17:19 raspberry dhcpcd[491]: eth0: adding address fe80::a8d9:c5d0:55ab:40fc
окт 28 05:17:19 raspberry dhcpcd[491]: eth0: soliciting an IPv6 router
окт 28 05:17:19 raspberry dhcpcd[491]: eth0: rebinding lease of 10.0.0.10
окт 28 05:17:19 raspberry dhcpcd[491]: eth0: probing address 10.0.0.10/24
окт 28 05:17:23 raspberry dhcpcd[491]: eth0: leased 10.0.0.10 for 86400 seconds
окт 28 05:17:23 raspberry dhcpcd[491]: eth0: adding route to 10.0.0.0/24
окт 28 05:17:23 raspberry dhcpcd[491]: eth0: adding default route via 10.0.0.1
окт 28 05:17:32 raspberry dhcpcd[491]: eth0: no IPv6 Routers available

Выходит, что мне юнит надо поднимать после dhcpd.service

Сделал так:

cat /etc/systemd/system/hammer.service

[Unit]
Description=Hammer Systemd Assistant
After=dhcpcd.service
Require=dhcpcd.service 

[Service]
ExecStart=/usr/local/bin/hammer -serve -ip 10.0.0.10 -port 4242
Type=simple

[Install]
WantedBy=multi-user.target

Потом сделал sudo systemctl daemon-reload

Перегрузился, НЕ помогает :(

Что интересно, когда смотрю systemctl list-dependencies hammer То там не вижу вообще ничего про сеть. Это так и должно быть?

Вот, блин, морока на ровном месте, лол :)

paddlewan ()
Ответ на: комментарий от paddlewan

Вот, блин, морока на ровном месте, лол

Да нет, не на ровном месте. Как systemd узнает, когда на интерфейсе появился адрес, если dhcpcd ему это не сообщает?

Выходит, что мне юнит надо поднимать после dhcpd.service

Нет, потому что как я уже написал, твой сетевой менеджер (в данном случае это голый dhcpcd) получает адрес асинхронно, и факт запуска dhcpcd ещё ничего не означает.

Тебе нужно выкинуть голый dhcpcd и перейти на полноценный сетевой менеджер — например, systemd-networkd или NetworkManager по вкусу. systemd-networkd гораздо проще, но если у тебя Wi-Fi, то это только NetworkManager. После этого сделать

systemctl enable NetworkManager NetworkManager-wait-online

…и добавить network.target с network-online.target (оба) в зависимости:

[Unit]
Wants=network.target network-online.target
After=network.target network-online.target
intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Сорян, сейчас будет много буков, но так удобнее.

systemd-networkd был утановлен, но disabled

До:

systemctl status systemd-networkd

● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-networkd.service(8)

Сделал: sudo systemctl reenable systemd-networkd

sudo systemctl reenable systemd-networkd-wait-online.service

Посмотрел, что ссылка установилась: ls /etc/systemd/system/network-online.target.wants/

ifupdown-wait-online.service  networking.service  systemd-networkd-wait-online.service

Что интересно, там еще вот эти ifupdown-wait-online.service и networking.service И они оба помечены active и enabled. Я что-то теряюсь :( Реально работает именно dchpcd (я статический адрес подставлял тут для одного эксперимента через его конфиг).

Исправил юнит и сделал sudo systemctl daemon-reload:

cat /etc/systemd/system/hammer.service

[Unit]
Description=Hammer Systemd Assistant
Wants=network.target network-online.target
After=network.target network-online.target

[Service]
ExecStart=/usr/local/bin/hammer -serve -ip 10.0.0.10 -port 4242
Type=simple

[Install]
WantedBy=multi-user.target

После перезагрузки картина такая:

systemctl status systemd-networkd

● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-10-28 15:55:22 MSK; 1min 30s ago
     Docs: man:systemd-networkd.service(8)
 Main PID: 170 (systemd-network)
   Status: "Processing requests..."
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/systemd-networkd.service
           └─170 /lib/systemd/systemd-networkd

окт 28 15:55:22 raspberry systemd[1]: Starting Network Service...
окт 28 15:55:22 raspberry systemd-networkd[170]: Enumeration completed
окт 28 15:55:22 raspberry systemd[1]: Started Network Service.
окт 28 15:55:39 raspberry systemd-networkd[170]: eth0: Gained carrier
окт 28 15:55:41 raspberry systemd-networkd[170]: eth0: Gained IPv6LL

systemctl status systemd-networkd-wait-online.service

● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; vendor preset: enabled)
   Active: active (exited) since Wed 2020-10-28 15:55:41 MSK; 1min 24s ago
     Docs: man:systemd-networkd-wait-online.service(8)
  Process: 193 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exited, status=0/SUCCESS)
 Main PID: 193 (code=exited, status=0/SUCCESS)

окт 28 15:55:23 raspberry systemd-networkd-wait-online[193]: ignoring: lo
окт 28 15:55:23 raspberry systemd-networkd-wait-online[193]: ignoring: lo
окт 28 15:55:24 raspberry systemd-networkd-wait-online[193]: ignoring: lo
окт 28 15:55:35 raspberry systemd-networkd-wait-online[193]: ignoring: lo
окт 28 15:55:35 raspberry systemd-networkd-wait-online[193]: ignoring: lo
окт 28 15:55:39 raspberry systemd-networkd-wait-online[193]: ignoring: lo
окт 28 15:55:39 raspberry systemd-networkd-wait-online[193]: ignoring: lo
окт 28 15:55:39 raspberry systemd-networkd-wait-online[193]: ignoring: lo
окт 28 15:55:41 raspberry systemd-networkd-wait-online[193]: ignoring: lo
окт 28 15:55:41 raspberry systemd[1]: Started Wait for Network to be Configured.

То есть и systemd-networkd и systemd-networkd-wait-online заработали.

Но картина не изменилась.

systemctl status hammer // мой юнит

● hammer.service - Hammer Systemd Assistant
   Loaded: loaded (/etc/systemd/system/hammer.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2020-10-28 15:55:41 MSK; 52s ago
  Process: 661 ExecStart=/usr/local/bin/hammer -serve -ip 10.0.0.10 -port 4242 (code=exited, status=1/FAILURE)
 Main PID: 661 (code=exited, status=1/FAILURE)

окт 28 15:55:41 raspberry systemd[1]: Started Hammer Systemd Assistant.
окт 28 15:55:41 raspberry hammer[661]: Using /usr/local/etc/hammer.conf config file
окт 28 15:55:41 raspberry hammer[661]: listen tcp 10.0.0.10:4242: bind: cannot assign requested address
окт 28 15:55:41 raspberry systemd[1]: hammer.service: Main process exited, code=exited, status=1/FAILURE
окт 28 15:55:41 raspberry systemd[1]: hammer.service: Failed with result 'exit-code'.
paddlewan ()
Ответ на: комментарий от intelfx

Не, подключение Ethernet.

Ладно, пойду читать мануалы и ковыряться в настройках, как в старые добрые времена :)

P.S.

В опенсорсе многое изменилось в лучшую сторону за последние 20 лет, но все равно тенденция к сохранению несовместимых друг с другом решений в разных дистрах не может не радовать, кнешн :)

Ну вот честно, ну епт, есть systemd. Есть network-online.target Почему было чувакам не позаботиться о том, чтобы оно делало то, что должно? Я сам пишу программы и у меня в голове не умещается такой подход. Если вкрячиваешь в дистрибутив эту историю, то почему и управление соединением не сделать таким, чтобы оно просто работало как задумано с т.з. systemd? :) Для меня это вопрос без ответа.

Понятно, что не такая простая это все история, но блин…

Короч, спасибо за поддержку, пойду ковыряться.

paddlewan ()
Ответ на: комментарий от paddlewan

Не, подключение Ethernet.

Тогда почему у тебя там wpa_supplicant в дочерних процессах dhcpcd?

Ладно, пойду читать мануалы и ковыряться в настройках, как в старые добрые времена

Да там нечего читать. Если у тебя правда Ethernet и ты хочешь networkd, тебе нужно написать ровно один конфиг из 4 строчек. Как твой интерфейс называется?

Ну вот честно, ну епт, есть systemd. Есть network-online.target Почему было чувакам не позаботиться о том, чтобы оно делало то, что должно?

Потому что понятие «компьютер подключен к сети» с точки зрения каждого пользователя может значить совершенно разные вещи.

Если вкрячиваешь в дистрибутив эту историю, то почему и управление соединением не сделать таким, чтобы оно просто работало как задумано с т.з. systemd? :) Для меня это вопрос без ответа.

Да, совершенно все вещи в мире кажутся очень простыми и элементарными, пока ты не начал изучать, как они на самом деле устроены и работают.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Сейчас картина по интерфейсам такая:

** ifconfig**

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.10  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::a8d9:c5d0:55ab:40fc  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:4a:c7:a3  txqueuelen 1000  (Ethernet)
        RX packets 38488  bytes 8100580 (7.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 43393  bytes 5554627 (5.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 124  bytes 9289 (9.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 124  bytes 9289 (9.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Насчет «подключен к сети» - согласен абсолютно. Я вот тут нашел неплохую телегу на эту тему: где как раз обсуждается, что с десяток вариаций можно назвать «подключением к сети». Совершенно согласен. Вот тут: https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html

И там как раз совет разработчику типа: а ты делай так, чтоб твою программу это вообще не волновало :) Поймал себя на том, что быстрее и проще сделать таймаут на поднятие соединения моей утилитой и пересобрать, чем разобраться в настройках операционки :)

Я не особо ною… Мне прекрасно понятен и смысл проблемы (как раз в разном понимании «поднята сеть»), и чего стоит собрать дистрибутив и поддерживать его. Очень ценю усилия людей, но блин :) :) :)

paddlewan ()
Ответ на: комментарий от paddlewan

10.0.0.10 — точно выдан DHCP? Или статический адрес?

Короче:

# /etc/systemd/network/eth0.network
[Match]
Name=eth0

[Network]
# Если DHCP:
DHCP=yes

# Если статический адрес:
Address=10.0.0.10/24
Gateway=10.0.0.1  # или что там у тебя
DNS=8.8.8.8  # аналогично

Всё. После этого включаешь networkd (если уже успел отключить опять) и отключаешь всё остальное, что у тебя связано с сетью (ifupdown, dhcpcd, не знаю что там ещё у тебя).

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)

intelfx почти всё рассказал

Как альтернативу могу предложить слушать :: или 0.0.0.0 вместо 10.0.0.10, ибо привязываться к IP в юните зло ;-)

ExecStart=/usr/local/bin/hammer -serve -ip '::' -port 4242

или

ExecStart=/usr/local/bin/hammer -serve -ip '0.0.0.0' -port 4242

ksim ()
Последнее исправление: ksim (всего исправлений: 2)
Ответ на: комментарий от ksim

Спасибо за комментарий. И да, огромное спасибо intelfx :) Сподвиг меня задуматься и почитать доки, на самом деле.

Да, я понимаю, что если слушать 0.0.0.0 или ::, то все должно заработать. Я уже выше писал, что можно вообще софтине моей сделать, например, аргумент командной строки типа -timeout и кол-во секунд, сколько ждать. Ну или там вообще несколько попыток реконнекта. Это бы заняло пять минут, но мне интереснее стало разобраться, как этот зоопарк у меня вообще работает.

Как видно из переписки выше, у меня вообще было параллельно установлено три системы работы с сетью - ifupdown, systemd-networkd и dhcpcd. Работал при этом реально только последний.

Как так случилось, я ума не приложу, ведь готовая сборка системы Raspberry просто заливается на флэшку. Сетевую подсистему я ВООБЩЕ не трогал руками до вчерашнего дня, только делал нужные мне настройки (samba, по части libinput кой-чего, ssh) ну то есть от слова совсем не трогал руками. Задаюсь вопросом, это что оно в таком виде в раздаваемой тысячам людей сборке лежит О_о? Короче, не понял, как это так получилось.

Выпилил в итоге ifupdown и с интересом читаю документацию по systemd-networkd и NetworkManager. Склоняюсь к тому, чтобы воспользоваться вторым. Он гораздо умнее, как мне показалось, и в GUI и в консоли. Есть nmcli, например, которым можно подцепиться к wifi, а в случае networkd, я так понял, надо лезть в /etc/wpa_supplicant/wpa_supplicant.conf на такое банальное действие, как подключение к Wifi сети.

Короч, хорошо, что я наткнулся на эту проблемку. И узнал много интересного про конфигурацию своей системы, и про управление сетью в моем дистрибутиве (и вообще про альтернативы, я долгий перерыв делал с Linux, поэтому не знал вообще ничего про эти штуки), ну и до кучи нашел удобный инструмент :)

Короче, сплошной позитив от ЛОРа словил :)

Кста, а почему привязываться к IP в юните - это зло? :) :) :) Поясни, плс. Вот представим себе, что у меня на машине несколько сетевых интерфейсов, которые смотрят в разные сети, например. 10.0.0.0 и 192.168.0.0 Если я буду слушать 0.0.0.0, то на запросы из какой сети я отвечу? :)

paddlewan ()
Ответ на: комментарий от intelfx

10.0.0.10 — точно выдан DHCP? Или статический адрес?

Ну конечно DHCP. Роутер по привязке по MAC отдает просто один и тот же адрес, поэтому такой красивый :) Это домашняя сетка и там всем адреса дадены не просто так, а чтобы всегда были одинаковые. Я по ssh хожу на разные машины постоянно просто :)

Огромное тебе спасибо, что буквально разжевал все, но еще большее за то, что подсказал, где почитать в итоге (см. пост выше). Я, пожалуй, все же NetworkManager возьму, т.к. Wifi тоже дорог, а через networkd, я так понял, надо руками сети добавлять в конфиг (не уверен, не дочитал еще доки).

paddlewan ()
Ответ на: комментарий от paddlewan

Задаюсь вопросом, это что оно в таком виде в раздаваемой тысячам людей сборке лежит О_о?

Почти уверен, что именно так.

Добро пожаловать в современные дистрибутивы, современный линукс и конкретно в дебиан. Свалка костылей-с.

Уберёшь ifupdown — хомячки взвоют, потому что туториал лохматых годов, найденный на Stack Overflow AskUbuntu по запросу «как сделать сеть на распберри пай бесплатно без смс», о ужас, теперь не подходит и нужно думать головой.

Уберёшь dhcpcd — другие хомячки взвоют, потому что они даже загуглить не могут и им нужно всё искаропки, а искаропки ниработаит.

Выпилил в итоге ifupdown и с интересом читаю документацию по systemd-networkd и NetworkManager. Склоняюсь к тому, чтобы воспользоваться вторым. Он гораздо умнее, как мне показалось, и в GUI и в консоли.

Да, NM гораздо умнее, это так задумано. networkd простой как палка — он писался для всяких серверов, как прямая замена дистроспецифичным костылям типа ifupdown, /etc/network/interfaces, netcfg, netctl и что там ещё бывает. NM же вообще пришёл с десктопов.

Кста, а почему привязываться к IP в юните - это зло? :) :) :) Поясни, плс. Вот представим себе, что у меня на машине несколько сетевых интерфейсов, которые смотрят в разные сети, например. 10.0.0.0 и 192.168.0.0 Если я буду слушать 0.0.0.0, то на запросы из какой сети я отвечу? :)

Из всех.

Не согласен, что это зло, бывают разные случаи. Просто интерфейс сокетов Беркли такой вот исторически слегка ущербный, что нельзя прибиндиться к адресу, которого ещё нет.

Правда, конкретно в линуксе можно — есть setsockopt(IP_FREEBIND). Если тебя не волнует совместимость с другими юниксами, вполне можно воспользоваться.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Добро пожаловать в современные дистрибутивы, современный линукс и конкретно в дебиан. Свалка костылей-с.

Да, точняк :) Умом-то это понятно. Я просто работаю в трех системах: Raspberry (Debian-based, про которую эта поучительная ветка), Ubuntu и MacOS. И везде это есть, но в Ubuntu и MacOS не в таких, наверное, масштабах :)

Ubuntu многим ужасна, но они не стесняются вычищать старый хлам, ИМХО. Я глубоко под капот не лазил, правда, т.к. мне нужно от системы всего лишь, чтобы был браузер, ssh, vim/nano и среда разработки в графике (Ну и чтобы голову не парила, конечно! :). Но, признаться, был удивлен, когда не нашел в ubuntu банального ifconfig (там ip используется).

Короче, согласен на 100%, обратная совместимость - да, зло. Но в этом конкретном случае, работало же оно как-то, пока руки не зачесались… Думаю, тут основная проблема в том, что когда ломаешь обратную совместимость (тот случай, про который ты говоришь: хомячки взвоют, что старый туториал не работает), то надо документировать новое решение исчерпывающе, либо делать его таким, чтобы даже идиоту было понятно без документации (одна кнопка, как в макоси, например и ффсе :) ). А вот документацию писать и красиво сложить на красивом сайте - это же отдельная охренеть непростая работа. Поэтому, наверное, иногда проще костыли оставить, и не париться, если оно работает :)

Не согласен, что это зло, бывают разные случаи. Просто интерфейс сокетов Беркли такой вот исторически слегка ущербный, что нельзя прибиндиться к адресу, которого ещё нет.

Ну я поэтому такой вопрос и задал человеку :) Мне надо чтобы конкретно на запросы из 10.0.0.0 сервис отвечал, а на другие - нифига :)

Про системный вызов этот я знаю тоже, но тут конкретно все написано на Go, а это такой язык, в который точно НЕ хочется тащить сишечку без крайней необходимости. Да и в С я не силен от слова совсем :)

paddlewan ()
Ответ на: комментарий от paddlewan

Кста, а почему привязываться к IP в юните - это зло?

потому, что на изменение конфигурации сети (новый роутер принёс)/dhcp не отвечает/сетевой провод не воткнул/итд, и начинаются танцы с бубном и поиски виноватого, у меня у самого около 5-6 самописных сервиса крутятся, я localhost c ними бинжу и через nginx проксирую, на внешние сети стоит аутентификация, на локалку/VPN свободный вход + прикручен https через letsencrypt, ну и никакой возни с портами всё корректно на 443 порту, а разные сервисы по разным путям отдаёт.

ksim ()
Ответ на: комментарий от ksim

я localhost c ними бинжу и через nginx проксирую, на внешние сети стоит аутентификация, на локалку/VPN свободный вход + прикручен https через letsencrypt, ну и никакой возни с портами всё корректно на 443 порту, а разные сервисы по разным путям отдаёт.

Нарядная схема, может тоже так сделаю.

paddlewan ()