fix: do not erase systemd environment variables

[lbarthon]

In some scenarios, one might need to call ListenFd::from_env many times. Due to those two problematic lines, this is impossible, as the first time will erase the environment, and all the others will be ListenFd::empty.

In case where one wants to call this from a library, or any such thing, it makes the library completely unusable. There is also no reason for it to mutate the environment like that. Keeping those variables has effectively no impact.

[mitsuhiko]

How do other systems do this? This seems risky to me. Then the user would have to manually remove them.

[curvature]

How do other systems do this? This seems risky to me. Then the user would have to manually remove them.

Systemd managed services can reload themselves by executing a child process of its very own executable(argv[0]), in which case the child process needs to inherit the systemd sockets just as its parent did. To me it's clearing the env vars, not keeping them that begs the question of justification.

[mitsuhiko]

I suppose the solution is to provide another API that does not unset it. I'm honestly not sure what the recommended path is. Originally when I used systemd it unset those variables under normal circumstances from my memory, but I can see that the sd_listen_fds function gives the user an option.

[septatrix]

How do other systems do this? This seems risky to me. Then the user would have to manually remove them.

Systemd managed services can reload themselves by executing a child process of its very own executable(argv[0]), in which case the child process needs to inherit the systemd sockets just as its parent did.

Services replacing themselves is strongly discouraged by systemd as they do not get a clean state environment

[septatrix]

I suppose the solution is to provide another API that does not unset it

Systemd offers a flag for this:

int sd_listen_fds(int unset_environment);
int sd_listen_fds_with_names(int unset_environment, char*** names);