Здравствуйте, k55, Вы писали:
k55>Вопрос, связаны ли эти "побочные эффекты" с тем что dropbear демон и вообще, что ожидать в случае записи в stderr в демоне?
Если верить systemd.service(5), то по-умолчанию дескриптор для stdout используется и для stderr.
Похоже дело в dropbear. Если его запустить без ключа -i (inetd mode) без перехода в бэкграунд то все работает и ошибка печатается на консоль.
Inetd режим супер-пупер сервера. Я так понимаю в этом режиме у него нет stdout/stderr. Сам dropbear ругается если пытаешься включить verbose вместе с inetd.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Здравствуйте, k55, Вы писали:
k55>Inetd режим супер-пупер сервера. Я так понимаю в этом режиме у него нет stdout/stderr. Сам dropbear ругается если пытаешься включить verbose вместе с inetd.
Смешались в кучу кони-люди. Во-первых, stdin, stdout и stderr есть всегда. Вопрос в том, куда они ведут. Я выше писал, что если сервис запущен через systemd socket activation, то stdin и stdout связаны с сокетом, а stderr, если верить документации systemd, дублирует значение stdout, то есть, тоже связан с сокетом. Далее, при чём тут inetd, если речь про systemd? Имеется в виду systemdd socket activation в режиме совместимости c systemd или что-то другое?
C>Смешались в кучу кони-люди. Во-первых, stdin, stdout и stderr есть всегда. Вопрос в том, куда они ведут. Я выше писал, что если сервис запущен через systemd socket activation, то stdin и stdout связаны с сокетом, а stderr, если верить документации systemd, дублирует значение stdout, то есть, тоже связан с сокетом. Далее, при чём тут inetd, если речь про systemd? Имеется в виду systemdd socket activation в режиме совместимости c systemd или что-то другое?
Спасибо, я теперь понял что имелось ввиду.
"Я выше писал, что если сервис запущен через systemd socket activation, то stdin и stdout связаны с сокетом, а stderr, если верить документации systemd, дублирует значение stdout"
Это ключевое. В сервисе для dropbear был указан только StandardInput=socket и как следствие все остальное тоже было сокетом.
Прописал StandardError=syslog+console и теперь ошибка попадает на консоль и в логи, ssh работает.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Здравствуйте, cppguard, Вы писали:
k55>>Inetd режим супер-пупер сервера. Я так понимаю в этом режиме у него нет stdout/stderr. Сам dropbear ругается если пытаешься включить verbose вместе с inetd.
C>Смешались в кучу кони-люди. Во-первых, stdin, stdout и stderr есть всегда.
Вообще-то нет. То, что что-то открыто на дескрипторах 0-2 — это правило хорошего тона, но не обязанность. Но тут речь явно не про этот случай.
C> Вопрос в том, куда они ведут. Я выше писал, что если сервис запущен через systemd socket activation, то stdin и stdout связаны с сокетом, а stderr, если верить документации systemd, дублирует значение stdout, то есть, тоже связан с сокетом. Далее, при чём тут inetd, если речь про systemd? Имеется в виду systemdd socket activation в режиме совместимости c systemd или что-то другое?
Я думаю, имеется в виду inetd-режим подчинённого демона.
В одном проекте, что сейчас ломаю, как раз sshd.socket в systemd запускает sshd%.service
с командой "sshd -i", а это -i как раз показывает sshd, что он запущен из-под inetd / xinetd / аналога (как systemd) на одно входящее соединение.
И если в самом сервере не доработано, что в этом состоянии не надо всякую хрень посылать на дефолтные дескрипторы — то он ССЗБ.
Здравствуйте, netch80, Вы писали:
N>Вообще-то нет. То, что что-то открыто на дескрипторах 0-2 — это правило хорошего тона, но не обязанность. Но тут речь явно не про этот случай.
Так никто не говорит, что нет возможности запустить программу так, чтобы чтение stdin сломалось, но, насколько мне известно, по-умолчанию всё таки stdin, stdout и stderr предоставлены процессу.
N>Я думаю, имеется в виду inetd-режим подчинённого демона. N>В одном проекте, что сейчас ломаю, как раз sshd.socket в systemd запускает sshd%.service N>с командой "sshd -i", а это -i как раз показывает sshd, что он запущен из-под inetd / xinetd / аналога (как systemd) на одно входящее соединение.
N>И если в самом сервере не доработано, что в этом состоянии не надо всякую хрень посылать на дефолтные дескрипторы — то он ССЗБ.
Тут соль в том, что socket activation умеет запускать программы, которые были разработаны под inetd, есть специальная опция для этого. Но механика передачи файловых дескрипторов меняется. Я не разбирался до конца, но точно знаю, что, например, в Java System.inheritedChannel() работает только в режиме совместимости с inetd. Поэтому я хотел уточнить, что там вообще происходит. Может вообще inetd одновременно с systemd работает?
Здравствуйте, cppguard, Вы писали:
C>Тут соль в том, что socket activation умеет запускать программы, которые были разработаны под inetd, есть специальная опция для этого. Но механика передачи файловых дескрипторов меняется. Я не разбирался до конца,
Есть дока, хоть и кривая: тут.
Тест показывает, что без опции inetd приходит один сокет номер 3.
Банально, проверка в духе "echo 123 1>&3" пишет в него, без этого — пишет куда-то на другой stdout.
Я не понял, почему дока говорит про несколько сокетов.
C> но точно знаю, что, например, в Java System.inheritedChannel() работает только в режиме совместимости с inetd. Поэтому я хотел уточнить, что там вообще происходит. Может вообще inetd одновременно с systemd работает?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, cppguard, Вы писали:
N>Я не понял, почему дока говорит про несколько сокетов.
Если флаг --inetd есть, то переиспользуются stdin/stdout процесса-демона. Если нет, то процесс наследует stdin/stdout порождающего процесса, а activated sockets доступны с fd=3 и далее, а их количество можно узнать из LISTEN_FDS или вызвав sd_listen_fds().
Здравствуйте, cppguard, Вы писали:
C>Здравствуйте, netch80, Вы писали:
N>>Я не понял, почему дока говорит про несколько сокетов.
C>Если флаг --inetd есть, то переиспользуются stdin/stdout процесса-демона. Если нет, то процесс наследует stdin/stdout порождающего процесса, а activated sockets доступны с fd=3 и далее, а их количество можно узнать из LISTEN_FDS или вызвав sd_listen_fds().
Каким образом возможно наличие нескольких activated sockets для входящих сетевых соединений?
These options may be specified more than once, in which case incoming traffic on any of the sockets will trigger service activation, and all listed sockets will be passed to
the service, regardless of whether there is incoming traffic on them or not. If the empty string is assigned to any of these options, the list of addresses to listen on is
reset, all prior uses of any of these options will have no effect.
Здравствуйте, cppguard, Вы писали:
C>Здравствуйте, netch80, Вы писали:
N>>Каким образом возможно наличие нескольких activated sockets для входящих сетевых соединений?
C>ListenStream=, ListenDatagram=, ListenSequentialPacket=
Я эту херь вроде видел. Я не могу понять, чего они добиваются. Что за сценарий когда это реально нужно?
TCP, SCTP — приняли соединение и с ним работаем. Когда другое придёт — ХЗ.
Слушать из-за этого другой сокет — мешать вероятному соседу делать то же самое.
UDP — вроде та же проблема.
Или это на тот вариант, что в классическом inetd звался wait?
Дело systemd захватить сокеты, а целевой программы — слушать?
Тогда и это вроде делается иначе.
Надо покопать, что пишут про сценарии для этого режима.
Здравствуйте, netch80, Вы писали:
N>Надо покопать, что пишут про сценарии для этого режима.
По-мойму, всё просто — слушать на разных интерфейсах. Как-минимум, PostgreSQL так умеет — и юникс сокет слушать, и сеть. Мне кажется, что в дизайне systemd нет какой-то хитрой идеи, разработчики просто пытаются подстроить систему под уже известные сценарии.
Здравствуйте, cppguard, Вы писали:
N>>Надо покопать, что пишут про сценарии для этого режима.
C>По-мойму, всё просто — слушать на разных интерфейсах.
Это не объясняет, зачем слушающие сокеты передавать в запущенный серверный процесс после этого.
C> Как-минимум, PostgreSQL так умеет — и юникс сокет слушать, и сеть.
