Bug 9771

(In reply to comment #0)
> There are two setenv() at the end of init_connections_unlocked() that look
> wrong.
>  - DBUS_ACTIVATION_BUS_TYPE is now called DBUS_STARTER_BUS_TYPE

Indeed.

>  - not sure whether DBUS_ACTIVATION_ADDRESS is still set or used

No, it's not (says git grep). DBUS_STARTER_ADDRESS is respected, though.

>  - if you dbus_shutdown() then re-init, the env variables would be gone, so we
> need to save them permanently in some way or something

It looks as though these setenv calls are entirely unnecessary anyway: init_connections_unlocked seems to be idempotent, and addresses_shutdown_func resets activation_bus_type and all three addresses, so they'll be re-retrieved from the environment. What was the point of the setenv calls? The commit introducing them, nearly 8 years ago, doesn't say:

commit eeb88949d8d2ca84d9cbe54c07e73b9907d3163e
Author: Havoc Pennington <hp@redhat.com>
Date:   2003-04-03 05:22:49 +0000

    2003-04-03  Havoc Pennington  <hp@pobox.com>
    
        * bus/config-parser.c (bus_config_parser_unref): free
        list of mechanisms, bug discovered by test suite enhancements
        (putting system.conf and session.conf into suite)
    
        * test/Makefile.am, test/test-service.c: add placeholder for a
        test service that we'll activate as part of test suite. Doesn't
        do anything yet.
    
        * dbus/dbus-sysdeps.c (_dbus_setenv): support unsetenv by
        setting NULL value, and use system malloc not dbus_malloc()
        when we have unavoidable memleakage.
    
        * dbus/dbus-bus.c (dbus_bus_get): fix bug where bus type of 0
        didn't work, and support DBUS_BUS_ACTIVATION.
    
        * bus/activation.c (child_setup): pass our well-known bus type to
        the child
    
        * bus/config-parser.c: support <type> to specify well-known type
    
        * doc/dbus-specification.sgml: document the env variables to
        locate well-known buses and find service activator

Havoc? Any idea why your commit eeb88949d8d2 did this?

We're on the way to remove them, #bug68308

see #bug68308