Yes I see. I understand now. I think - as you suggest - it's best to
stop the service from forking if started by systemd.
S. Bon
27.06.2025 17:50, Stef Bon wrote:
Ok. The environment variable won't change when calling sd_notify.
I understand that. But how can I make socket activation work after
the main process osns system has forked? Is it required to fork
anyway
Invoke sd_listen_fds before fork, parse LISTEN_FDS
Op vr 27 jun 2025 om 15:23 schreef Andrei Borzenkov :
>
>
> 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 th
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
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 t
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 t
I've done the same, and even written some policy kit examples.
But it's difficult to surmise all the 'deltas' from 'sudo', and thus why having
some form of documentation from the team delivering this would help countless
others.
In the case of 'run0', does appear it really is layering upon what
> On 26 Jun 2025, at 17:58, SCOTT FIELDS wrote:
>
> I never said it was a drop-in replacement.
>
> But if the goal is to use this instead of "sudo", some migration
> documentation would help quite a bit.
>
> I know the implementation will not work with current "sudoers"
> configurations, no
