Why does _dbus_exit call _exit?

[Havoc Pennington]

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[1]). 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.

It's probably tough to argue that 
dbus_connection_set_exit_on_disconnect() should use _exit, though.

Havoc

[1]
  - 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.