Name release issue

[Simon McVittie]

On 28/06/16 07:09, Antoine Aubert wrote:
> Thanks, well, I solve the issue: Process B was spawn by forking process
> A. Means B inherits FD table of process A, even A is killed, unix socket
> client still live in B.

As a general rule of programming on Unix, every file descriptor should
be CLOEXEC except for the ones you specifically want to be inherited by
children (which normally means stdin, stdout and stderr).

Unix kernels can't fix this by changing the default FD_CLOEXEC flag on
newly opened fds, because that would be a major compatibility break, but
they can (and do) provide APIs that make it easier and more thread-safe,
such as Linux's open(..., ..., ... | O_CLOEXEC) and socket (..., ... |
SOCK_CLOEXEC, ...) syscalls.

libdbus is very careful to mark every file descriptor it opens as
CLOEXEC; our normal pattern is to try to use a syscall variation that
makes the fd CLOEXEC atomically, and if that fails, use fcntl F_SETFD as
a follow-up step (which is not fully thread-safe, but is the best we can
do if your kernel or libc doesn't support the atomic version). If you
find an instance of libdbus forgetting to do that, please report it as a
bug. The other major D-Bus implementations (GLib's GDBus and systemd's
sd-bus) have a similar policy.

> Fixed by using fcntl(fd, F_SETFD, FD_CLOEXEC), when I dup libbus fd for
> watcher.

You should not normally have any reason to dup the fd of a D-Bus connection.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>