Why does _dbus_exit call _exit?

[Padraig O'Briain]

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

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.
>
> 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.