É fácil quando você sabe como:)
$ systemctl list-sockets
LISTEN UNIT ACTIVATES
...
/run/systemd/journal/dev-log systemd-journald-dev-log.socket systemd-journald.service
/run/systemd/journal/socket systemd-journald.socket systemd-journald.service
/run/systemd/journal/stdout systemd-journald.socket systemd-journald.service
...
25 sockets listed.
Pass --all to see loaded but inactive sockets, too.
ok, eu menti sobre isso ser tão fácil. Eu não tenho um daemon syslog, e isso significa que eu não tenho syslog.socket ativado. Mas foi aí que encontrei os documentos:
$ systemctl cat syslog.socket
# /usr/lib/systemd/system/syslog.socket
...
Documentation=man:systemd.special(7)
Documentation=http://www.freedesktop.org/wiki/Software/systemd/syslog
...
# The default syslog implementation should make syslog.service a
# symlink to itself, so that this socket activates the right actual
# syslog service.
#
# Examples:
#
# /etc/systemd/system/syslog.service -> /lib/systemd/system/rsyslog.service
# /etc/systemd/system/syslog.service -> /lib/systemd/system/syslog-ng.service
#
# Best way to achieve that is by adding this to your unit file
# (i.e. to rsyslog.service or syslog-ng.service):
#
# [Install]
# Alias=syslog.service
#
# See http://www.freedesktop.org/wiki/Software/systemd/syslog for details.
link diz:
Note that it is now the journal that listens on /dev/log, no longer the BSD syslog daemon directly. If your logging daemon wants to get access to all logging data then it should listen on /run/systemd/journal/syslog instead via the syslog.socket unit file that is shipped along with systemd. On a systemd system it is no longer OK to listen on /dev/log directly, and your daemon may not bind to the /run/systemd/journal/syslog socket on its own. If you do that then you will lose logging from STDOUT/STDERR of services (as well as other stuff).
Assim, a resposta à sua pergunta é que você não deve usar nenhum desses caminhos com unix-dgram() . Você realmente precisa de suporte específico ao systemd se quiser rodar como um daemon syslog sob ele.
Para uma configuração individual, parece que você pode se livrar de /run/systemd/journal/syslog . Esta é definitivamente a opção menos malvada, porque a) evita lutar com o journald sobre quem possui /dev/log , b) o journald escreverá mensagens para ele a partir de STDOUT / STDERR de serviços, que nunca são gravados em /dev/log . Dado que aparece para funcionar, não vejo nenhuma desvantagem explícita listada nos documentos. A desvantagem óbvia é que "não recomendamos mais que as pessoas solicitem suas unidades após syslog.target ... mensagens de inicialização antecipada são perdidas completamente para a sua implementação". Há também um aviso de que "muitos serviços não poderão efetuar login na implementação do syslog", mas acho que isso é incorreto / só se aplica se você ouvir /dev/log .