<div dir="auto">The systemd APIs to receive the socket check that the PID matches that of the original process and otherwise returns. I assume you are running into this. This is a deliberate decision as otherwise things might go awry if multiple processes assume they can use the same socket. Ideally you would also update to service to stop it from forking entirely and make it a normal Type=simply|notify.<div dir="auto"><br></div><div dir="auto">Or you could manually obtain the FD and ensure correctness yourself</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jun 27, 2025, 16:39 Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com">arvidjaar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">27.06.2025 14:59, Stef Bon wrote:<br>
> Hi,<br>
> <br>
> I've got a system daemon, and I want to make use of socket activation. It has a<br>
> socket /run/osns/system.sock, where clients belonging to user sessions<br>
> can connect to.<br>
> <br>
> What I've tried I do not get it to work.<br>
> It used to fork, and the forked process created the socket. I've<br>
> changed this using the code on<br>
> <a href="http://0pointer.de/blog/projects/socket-activation.html" rel="noreferrer noreferrer" target="_blank">http://0pointer.de/blog/projects/socket-activation.html</a><br>
> <br>
> the osns-system.socket file:<br>
> <br>
> [Socket]<br>
> ListenStream=/run/osns/system.sock<br>
> <br>
> [Install]<br>
> WantedBy=socket.target<br>
> <br>
> and osns-system.service file<br>
> <br>
> [Unit]<br>
> Description=OSNS System Service<br>
> After=syslog.target<br>
> <br>
> [Service]<br>
> Type=forking<br>
> KillMode=process<br>
> ExecStart=/usr/libexec/osns/osnssystem<br>
> Restart=no<br>
> <br>
> [Install]<br>
> WantedBy=multi-user.target<br>
> <br>
> I've used sd-listen_fds to get the fd when the socket<br>
> /run/osns/system.sock is created, but there is none. The environment<br>
> var LISTEN_PID is the pid of the process before forking. So the<br>
> session manager is not aware of the new main process. So I've added<br>
> <br>
> PIDFile=/run/osns/osns-system.pid<br>
> <br>
> to the [Service], but no effect.<br>
> I've changed the Type to notify, and make sd aware of the new pid<br>
> using sd_notifyf(0, "READY=1\n" "MAINPID=%lu", (unsigned long) pid)<br>
> where the pid is of the new forked process.<br>
> I've used this call in the starting process, and when that did not<br>
> work, used it in the new forked process.<br>
> That also did not work.<br>
<br>
The famous "it does not work". What you did, what results you got, what <br>
result did you expect?<br>
<br>
> The environment var LISTEN_PID remains the pid<br>
> of the starting process.<br>
<br>
How do you expect this environment variable to change? It was set when <br>
systemd invoked your program. How systemd is supposed to change the <br>
value of this variable inside already started process? How systemd is <br>
supposed to predict the value of PID before starting your command?<br>
<br>
> What is wrong?<br>
> <br>
<br>
It is still unclear what you did. But I venture to guess you should not <br>
use Type=forking or process passed file descriptors before forking.<br>
</blockquote></div>