В продолжении разговора.

Ваять systemd-style конфиги для ntpd пока не охота. Полез в /etc/rc3.d и офигел.
Раньше какие только порядковые номера там не видел, а теперь всё как-то скомкано. Да, ntp был в первой партии, но там был и bind, а bind-у больше ничего не было нужно кроме работающего интерфейса.
А сейчас бинду нужен, как минимум, dnscrypt-proxy. Или, на худой конец, tor-resolver. #нуивот.
Но раньше и тор, и transmission-daemon были двадцатыми, а сейчас какая-то скотина сделал тор четвёртым, а трансмишин вообще первым. И это не смотря на то, что в настройках трансмишина чётко написано запускать после тора, бинда и привокси.
В общем, для начала отодвинул ntp по порядку подальше.
С остальным ещё предстоит разбираться.

systemd, как некая хрень, данная нам в наказание, чтобы жизнь мёдом не казалась.

Началось всё, конечно, гораздо раньше, но конкретно эта история началась с желания добиться от privoxy адекватной работы. Нет, конечно, он работает правильно. Но основная его задача — вставлять в запросы от transmission к аннонсерам строчки x-forwarded-for. Дабы аннонсеры знали его рабочий адрес, не принимая за таковой адрес выходной ноды. То есть конструкция довольно простая: transmission, iptables, privoxy, tor, аннонсеры. Чуток её усложняет dnscrypt-proxy, предназначенный для противодействия MITM-атакам. Сначала, правда, пытался заюзать tor-resolve, но безопасный ресолвинг сходу получить не вышло, потому и переключился на dnscrypt. Сейчас-то понимаю, что проблема могла быть в том, что tor был тогда не в достаточной степени адаптирован под изменившиеся обстоятельства и, imho, выходная нода попадала под MITM-атаку. Потом всё-равно пришлось делать "тонкую настройку" тору, но на dnscrypt так и остался. IMHO, он всё-таки лучше, чем tor-resolve.
Итого, клиент ресолвит адрес через dnscrypt, шлёт анонсы на трекеры, но их перехватывает iptables и отправляет к privoxy. Тот дописывает x-forwarded-for и заталкивает в тор. В результате анонсеры узнают реальный адрес и отдают его пирам.
Но transmission находится за роутером, который имеет динамический адрес и не знает свой адрес.
Да и никто его не знает. Как-то штудировал протоколы, по которым transmission запрашивает проброс порта и что-о не нашёл штатного способа об этом узнать. Хрень какая-то.
А как-же его узнать?
Варинта вижу два.
1). Идти на роутер и выпарсивать адрес из его страничек. Но это долго и нудно.
2). Можно кого-нибудь спросить. Например на api.apify.org или у wtfismyip.com. Которые дают чистый адрес без необходимости выискивать его на странице. Подсмотрел у друзей по несчастью и клонировал демона, который периодически узнаёт рабочий адрес и подсказывает его privoxy.
И всё было прекрасно, до тех пор пока на пол-дня transmission не потерял связь с трекерами.
С чего бы это?
А с того, что privoxy упал
А почему он упал?
А потому что демон внешнего адреса (назовём его Еидом) был тупой (дарёному демону в зубы не смотрят) и когда вместо адреса получил какую-то хрень, то попортил "зону комфорта" для privoxy, который упал на пол, стал стучать ножками и отказался дальше работать. Еиду-то что — его к жизни всякий раз возвращает кронос, а привокси на такое не был расчитан.
Ну, понятное дело, что скил демона был прокачан, дабы тот впредь сообщал привокси только внятный валидный адрес. Но грусть в душу запала, ибо надеяться на чужие ресурсы, которые могут отвалиться, отсплититься или ещё какая напасть возникнет, негоже. Придётся писать собственного демона, который внешний адрес будет узнавать у роутера.
И казалось бы, всё заработало, но тут-то и выходит весь из себя systemd.
Надо сказать, что я на него давно уже зуб имею. Странный какой-то, запутанный, дурной. Чтобы ковырять, надо кучу терминалов открыть, потому что разные конфиги в куче разных мест, весьма далёких друг от друга. А ещё он сразу невзлюбил miredo. И второй интерфейс на компе тоже. А из-за него якобы networking не поднимается. То есть, по факту он всё-таки поднят. Но поскольку при его поднятии второй интерфейс обругал, что он и так уже запущен, то systemd его пометила как failed.
Так вот, задумался я, что Еид должен быть запущен перед privoxy, дабы прописать правильный адрес до того, как тот начнёт рассылать недостоверную информацию. Но тогда и transmission должен быть запущен только после privoxy. А privoxy должен быть запущен после tor. Ну, и так далее.
Сначала, конечно, накосячил :)
Во-первых, conntrack нельзя, оказывается, настраивать до того, как загружен модуль ;)
И transmission вообще не запустился. Может потому что загнал ему в after networking.target, а networking у меня, как помните, failed.
Зато потом, внимательно поразмыслив кто после кого должен запускаться и удалив некоторые избыточные (и, видимо, запутывающие) зависимости, довёл до нужного вида. В результате чего, даже networking стал подниматься без fail.
Сегодня была как раз вторая (внеплановая) перезагрузка и в этот раз тоже всё поднялось как нужно.