Исходное сообщение
"Релиз Debian 9.0 Stretch намечен на 17 июня" Отправлено Аноним, 29-Май-17 19:42
socat был необходим лишь для эксперимента, чтобы убедиться, что данные в сокет вообще уходят. То, что они приходят к демону понятно и так, т.к. не было возвращено ошибок. Соответственно на стороне сервера была исполнена read(). Вообщем, обходной путь найден, но в systemd ошибка присутствует. systemd-notify абсолютно неработоспособна. Пока могу предполагать, что проблема из-за того, что systemd пытается определить принадлежность к cgroups по PID. Но делает это после того, как сообщение было получено. Соответственно, процесс уже завершился, а сообщение игнорируется, т.к. невозможно было определить cgroup. Идея интересная, - один сокет на все процессы, но реализация, похоже, неграмотная. Я бы в протокол добавил обязательно ожидание подтверждения от демона того, что сообщение получено. Блокирующийся read() не дал бы процессу завершиться и можно было бы определить его cgroup. Но как именно там реализовано пока не знаю. Обходной путь - переписать скрипт c bash на python и использовать systemd.daemon.notify('READY=1'). Пока устраивает. Отчёт об ошибке отправлен в Debian. Сам я пытался найти место, где происходит приём сообщений, но пока не нашёл. Код там нельзя назвать интуитивно понятным. Нашёл функцию, которая определяет cgroup по PID, но по её вызовам не нашёл абсолютно ничего полезного. Даже по слову READY я не смог найти место, где данная строка обрабатывается.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> socat был необходим лишь для эксперимента, чтобы убедиться, что данные в сокет > вообще уходят. То, что они приходят к демону понятно и так, > т.к. не было возвращено ошибок. Соответственно на стороне сервера была исполнена > read(). > Вообщем, обходной путь найден, но в systemd ошибка присутствует. systemd-notify абсолютно > неработоспособна. Пока могу предполагать, что проблема из-за того, что systemd пытается > определить принадлежность к cgroups по PID. Но делает это после того, > как сообщение было получено. Соответственно, процесс уже завершился, а сообщение игнорируется, > т.к. невозможно было определить cgroup. Идея интересная, - один сокет на > все процессы, но реализация, похоже, неграмотная. Я бы в протокол добавил > обязательно ожидание подтверждения от демона того, что сообщение получено. Блокирующийся > read() не дал бы процессу завершиться и можно было бы определить > его cgroup. Но как именно там реализовано пока не знаю. > Обходной путь - переписать скрипт c bash на python и использовать systemd.daemon.notify('READY=1'). > Пока устраивает. > Отчёт об ошибке отправлен в Debian. Сам я пытался найти место, где > происходит приём сообщений, но пока не нашёл. Код там нельзя назвать > интуитивно понятным. Нашёл функцию, которая определяет cgroup по PID, но по > её вызовам не нашёл абсолютно ничего полезного. Даже по слову READY > я не смог найти место, где данная строка обрабатывается.
	Введите код, изображенный на картинке: