27.06.2025 14:59, Stef Bon wrote:
Hi,
I've got a system daemon, and I want to make use of socket activation. It has a
socket /run/osns/system.sock, where clients belonging to user sessions
can connect to.
What I've tried I do not get it to work.
It used to fork, and the forked process created the socket. I've
changed this using the code on
http://0pointer.de/blog/projects/socket-activation.html
the osns-system.socket file:
[Socket]
ListenStream=/run/osns/system.sock
[Install]
WantedBy=socket.target
and osns-system.service file
[Unit]
Description=OSNS System Service
After=syslog.target
[Service]
Type=forking
KillMode=process
ExecStart=/usr/libexec/osns/osnssystem
Restart=no
[Install]
WantedBy=multi-user.target
I've used sd-listen_fds to get the fd when the socket
/run/osns/system.sock is created, but there is none. The environment
var LISTEN_PID is the pid of the process before forking. So the
session manager is not aware of the new main process. So I've added
PIDFile=/run/osns/osns-system.pid
to the [Service], but no effect.
I've changed the Type to notify, and make sd aware of the new pid
using sd_notifyf(0, "READY=1\n" "MAINPID=%lu", (unsigned long) pid)
where the pid is of the new forked process.
I've used this call in the starting process, and when that did not
work, used it in the new forked process.
That also did not work.
The famous "it does not work". What you did, what results you got, what
result did you expect?
The environment var LISTEN_PID remains the pid
of the starting process.
How do you expect this environment variable to change? It was set when
systemd invoked your program. How systemd is supposed to change the
value of this variable inside already started process? How systemd is
supposed to predict the value of PID before starting your command?
What is wrong?
It is still unclear what you did. But I venture to guess you should not
use Type=forking or process passed file descriptors before forking.
