Re: Name release issue
Simon McVittie <simon.mcvittie-ZGY8ohtN/[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Organization | Collabora Ltd. |
| Message-ID | <[email protected]> |
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/> _______________________________________________ dbus mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dbus