Why does _dbus_exit call _exit?
Padraig.Obriain at Sun.COM
Tue Oct 3 07:46:08 PDT 2006
Havoc Pennington wrote:
> Padraig O'Briain wrote:
>> I have been looking at why ORBit2 leaves stale sockets in
>> $TMPDIR/orbit-padraigo when I log out.
>> I noticed that /usr/lib/gnome-vfs-daemon always left its stale ORBit
>> socket behind.
>> This program exits when dbus_connection_dispatch calls _dbus_exit.
>> The function _dbus-exit calls _exit instead of exit.
>> When _exit is called instead of exit the at_exit handler is not
>> called so ORBit does not clean up.
> I believe it was originally because I was using dbus_exit after a
> fork, so didn't want the child to call the parent's atexit handlers.
> (One of the many nasty aspects of atexit handlers). dbus_exit then
> happened to be used also for the
> dbus_connection_set_exit_on_disconnect() feature.
> The way dbus addresses the stale sockets problem on linux is to use
> abstract sockets, and on other platforms it has dbus-cleanup-sockets
> which can be run in a cron job or on logout or whenever.
> dbus-cleanup-sockets is copied from orbit, I think the orbit version
> isn't installed though so can't be run in cron. That's what I would
> suggest doing with orbit.
I found the program linc-cleanup-sockets. I assume that is the program
you are referring to. This program cleans up the orbit sockets only for
the user who runs the program.
> It's probably tough to argue that
> dbus_connection_set_exit_on_disconnect() should use _exit, though.
> - they run in semi-undefined order (order of registration)
> - there's an arbitrary max number of them and no way to really respond
> if it's exceeded or know it's exceeded
> - you can't remove them if you want to uninit or unload what added them
> - they run in child processes also if you fork and screw up the parent
> - the big one - they don't run on abnormal exit, so can't possibly do
> anything that genuinely needs doing
> the only real benefit of exit() afaik is that it flushes stdout.
More information about the dbus