История изменений

Ты не понимаешь, как работает socket-активация в systemd. Она требует специальной поддержки со стороны запускаемого приложения (в данном случае dnscrypt-proxy).

Вкратце: на раннем этапе загрузки (ещё до монтирования ФС) systemd проходит по всем *.socket-файлам и сам открывает все перечисленные в них сокеты. Таким образом складывается впечатление, что программа уже работает и к ней можно подключаться, хотя на самом деле нет. Когда же в сокет в конце концов прилетают какие-то данные (кто-то хочет подключиться) — systemd не трогает эти данные, оставляя их во внутриядерном буфере, но запускает основную программу (*.service-файл). Дальше самое главное: эта программа должна специальным образом «забрать» у systemd уже открытый сокет, в котором уже есть какие-то данные, и обработать их.

Соответственно, чтобы сказать программе, что она должна не сама открывать нужный сокет, а забирать из systemd уже готовый, мы используем немного другие параметры командной строки (ExecStart=/usr/local/sbin/dnscrypt-proxy -R dnscrypt.eu-nl).

Если написать ExecStart=/usr/sbin/dnscrypt-proxy -R dns.server.name -a 127.0.0.2:53, то dnscrypt-proxy сам попытается открыть сокет на порту 53 и обломается, потому что этот сокет уже был открыт самим systemd.

В итоге есть два варианта:

выкинуть *.socket-файл и указать порт в командной строке dnscrypt-proxy, со всеми вытекающими (dnscrypt-proxy будет запущен только в конце загрузки, что может быть неприемлемо для тебя — все программы, которые по стечению обстоятельств сделают DNS-запросы до запуска dnscrypt, либо обломаются, либо уйдут во второй по списку ресолвер, обходя dnscrypt, если у тебя в resolv.conf не только 127.0.0.1);
оставить всё как есть, т. е. взять *.socket- и *.service-файлы из первоисточника (.socket, .service).

Ты не понимаешь, как работает socket-активация в systemd. Она требует специальной поддержки со стороны запускаемого приложения (в данном случае dnscrypt-proxy).

Вкратце: на раннем этапе загрузки (ещё до монтирования ФС) systemd проходит по всем *.socket-файлам и сам открывает все перечисленные в них сокеты. Таким образом складывается впечатление, что программа уже работает и к ней можно подключаться, хотя на самом деле нет. Когда же в сокет в конце концов прилетают какие-то данные (кто-то хочет подключиться) — systemd не трогает эти данные, оставляя их во внутриядерном буфере, но запускает основную программу (*.service-файл). Дальше самое главное: эта программа должна специальным образом «забрать» у systemd уже открытый сокет, в котором уже есть какие-то данные, и обработать их.

Соответственно, чтобы сказать программе, что она должна не сама открывать нужный сокет, а забирать из systemd уже готовый, мы используем немного другие параметры командной строки (ExecStart=/usr/local/sbin/dnscrypt-proxy -R dnscrypt.eu-nl).

Если написать ExecStart=/usr/sbin/dnscrypt-proxy -R dns.server.name -a 127.0.0.2:53, то dnscrypt-proxy сам попытается открыть сокет на порту 53 и обломается, потому что этот сокет уже был открыт самим systemd.

В итоге есть два варианта:

выкинуть *.socket-файл и указать порт в командной строке dnscrypt-proxy, со всеми вытекающими (dnscrypt-proxy будет запущен только в конце загрузки, что может быть неприемлемо для тебя — все программы, которые сделают DNS-запросы до запуска dnscrypt, либо обломаются, либо направят их во второй по списку ресолвер, обходя dnscrypt, если у тебя в resolv.conf не только 127.0.0.1);
оставить всё как есть, т. е. взять *.socket- и *.service-файлы из первоисточника (.socket, .service).

Ты не понимаешь, как работает socket-активация в systemd. Она требует специальной поддержки со стороны запускаемого приложения (в данном случае dnscrypt-proxy).

Вкратце: на раннем этапе загрузки (ещё до монтирования ФС) systemd проходит по всем *.socket-файлам и сам открывает все перечисленные в них сокеты. Таким образом складывается впечатление, что программа уже работает и к ней можно подключаться, хотя на самом деле нет. Когда же в сокет в конце концов прилетают какие-то данные (кто-то хочет подключиться) — systemd не трогает эти данные, оставляя их во внутриядерном буфере, но запускает основную программу (*.service-файл). Дальше самое главное: эта программа должна специальным образом «забрать» у systemd уже открытый сокет, в котором уже есть какие-то данные, и обработать их.

У тебя есть два варианта:

выкинуть *.socket-файл, со всеми вытекающими (dnscrypt-proxy будет запущен только в конце загрузки, что может быть неприемлемо для тебя — все программы, которые сделают DNS-запросы до запуска dnscrypt, либо обломаются, либо направят их во второй по списку ресолвер, обходя dnscrypt, если у тебя в resolv.conf не только 127.0.0.1);
взять *.socket- и *.service-файлы из первоисточника (.socket, .service).

Ты не понимаешь, как работает socket-активация в systemd. Она требует специальной поддержки со стороны запускаемого приложения (в данном случае dnscrypt-proxy).

Вкратце: на раннем этапе загрузки (ещё до монтирования ФС) systemd проходит по всем *.socket-файлам и сам открывает все перечисленные в них сокеты. Таким образом складывается впечатление, что программа уже работает и к ней можно подключаться, хотя на самом деле нет. Когда же в сокет в конце концов прилетают какие-то данные (кто-то хочет подключиться) — systemd не трогает эти данные, оставляя их во внутриядерном буфере, но запускает основную программу (*.service-файл). Дальше самое главное: эта программа должна специальным образом «забрать» у systemd уже открытый сокет, в котором уже есть какие-то данные, и обработать их.

У тебя есть два варианта:

выкинуть *.socket-файл, со всеми вытекающими (dnscrypt-proxy будет запущен только в конце загрузки, что может быть неприемлемо для тебя);
взять *.socket- и *.service-файлы из первоисточника (.socket, .service).