(скопировано из SU , где это по тем или иным причинам было закрыто)
systemd и syslogd не регистрируют вызовы сокетов.
Агент Check _MK -является «службой inetd» — это означает, что он не работает постоянно и не создает собственный сокет слушателя; вместо этого он полагается на "суперсервер" для выполнения этой работы. Каждое новое соединение принимается суперсервером, который затем запускает новую копию Check _MK для обработки этого конкретного соединения.
Традиционно для этой цели используются суперсерверные программы inetd
или xinetd
. Однако ваша недавно установленная система использует функцию «активации сокета» systemd для достижения того же самого — в этой системе сокет слушателя представлен модулем .socket
, а каждый новый экземпляр представлен новым автоматически сгенерированным модулем .service
..
Таким образом, сообщение журнала вовсе не о доступе к сокету — оно буквально говорит, что служба была запущена. Нет возможности отключить ведение журнала запуска службы.
Чтобы избавиться от этого сообщения, деактивируйте модуль systemd.socket и перенастройте агент Check _MK -так, чтобы он запускался через xinetd (или традиционный inetd, или любой другой альтернативой ).
Краткий ответ: ядру приходится иметь дело со многими различными ситуациями/приложениями/аппаратными средствами. Повторная реализация стека выполняется, когда вы знаете потребности своего оборудования и/или связи вашего приложения. Затем вы можете кодировать только для этой вселенной.
Допустим, у вас есть небольшое сенсорное устройство, которое периодически отправляет данные по протоколу UDP.Вы можете создавать пакеты UDP/IP с большинством фиксированных значений, чтобы они доходили до сервера (вы знаете свой IP, свой порт, порт назначения и адрес, длину сообщения, флаги... вам просто нужно изменить показания ).
Запуск полного стека IP-ядра только для этого был бы излишним, медленным и, возможно, даже невыполнимым(запуск внутри голых костей Arduino , например ).
Но более широкий ответ более сложен, поэтому я предлагаю статью:Почему мы используем TCP-стек ядра Linux , ссылка на которую приведена внизу цитируемой вами статьи.
Частично это позволяет избежать некоторых переходов через границу системного вызова.
Это верно, но другой аспект заключается в том, что интерфейс системных вызовов Linux одновременно является очень общим (, т.е. должен иметь дело со многими различными типами приложений и систем ), и очень узким (параметры системных вызовов очень важны. конкретно с текущим запросом только ). Ядро обычно почти не знает, что ваш код будет делать дальше.
Возьмем в качестве примера find
. Он тратит много времени на системные вызовы, такие как getdents
и opendir
. Вы можете делать многое с помощью find
, но вот типичная командная строка:
find. -name 'report_201[89].txt' -print -quit
Программа find
будет открывать много каталогов и читать множество имен файлов. Он собирается передать эти имена файлов пользовательской -космической функции fnmatch
, чтобы узнать, являются ли они report_2018.txt
или report_2019.txt
.
Но давайте предположим, что .
находится в какой-то современной файловой системе. Каталоги на самом деле представляют собой B -деревья или хеш-таблицы. Если бы только ядро знало, какое имя файла мы ищем, мы могли бы сократить объем обработки.
Предположим, вместо этого мы рассмотрим git status
. Если вы проследите его системные вызовы, он выдает массу вызовов lstat
. Но на самом деле он пытается выяснить, изменил ли пользователь файловую систему? Ядро в основном знает ответ, но git
не может сообщить ядру, что оно хочет знать. Так что ему приходится все проверять самому (, хотя и делает он это довольно ловко ).
Основная идея здесь заключается в том, что все могло бы быть намного эффективнее, если бы API ядра -зависело от приложения. Но с точки зрения дизайна -это безумие, потому что существует так много разных приложений. Поддержание гораздо более широкого интерфейса ядра, вероятно, имеет сверх-линейную сложность. Но именно поэтому эффективность достигается за счет решения большего количества задач (для некоторых задач )в пользовательском -пространстве.