dbus patched with launchd support and version dump

[jonas.baehr@…]

This port is an alternative version of the current dbus port which integrates a patch providing autolaunch support via launchd. It also dumps the version to 1.2.12

Because autolaunching is now done via launchd, the X11 variant is no more necessary. X11 was only used to store the address of the session bus which is now done via launchd. X11 is now completely disabled (no more poping X11 windows for native applications!).

This should solve all the problems related to dbus autolaunching, like #16833, #16755, #16870 or #17688. Some of them are solved by building dbus with x11 support, but this is in my eyes a bad solution, esp. for non-x11 programs like kde4.

The original dbus patch can be found at  https://bugs.freedesktop.org/show_bug.cgi?id=14259

[jonas.baehr@…]

With this port, dbus-legacy, see r44934, is no more necessary.

[illogic-al@…]

Thanks a lot jonas. I suspect we'll need to clean up the portfile more to remove the LaunchDaemon created by macports (provided this works for everybody) but I'll leave this alone for now. Also I've included a no_x11 variant and enabled it by default (as we discussed). This alleviates any problems for those who already have this working (although the changes to how dbus-daemon is launched may cause problems initially). Ah well. Another day another ticket. Thanks again.

Fixed in r45206.

[jonas.baehr@…]

Replying to illogic-al@…:

Thanks a lot jonas. I suspect we'll need to clean up the portfile more to remove the LaunchDaemon created by macports (provided this works for everybody) but I'll leave this alone for now.

No, since they are for different busses. The startup item created by the Portfile starts up the system bus. This one is unique for the whole system and has one known address. The other one, the session bus, is unique per session, meaning every user got his own bus. Launchd is used to manage this address like X11 does on other Linux/*NIX

Also I've included a no_x11 variant and enabled it by default (as we discussed). This alleviates any problems for those who already have this working (although the changes to how dbus-daemon is launched may cause problems initially).

I've got some concerns about that one. X11 is used, just like launchd, only to store the session bus address. Having both doesn't make sense and my break something. I would really prefer to drop it completely or at least, disable launchd when using x11. But the Portfile you've checked in seems odd to me.

[illogic-al@…]

Replying to jonas.baehr@…:

Replying to illogic-al@…:

Thanks a lot jonas. I suspect we'll need to clean up the portfile more to remove the LaunchDaemon created by macports (provided this works for everybody) but I'll leave this alone for now.

No, since they are for different busses. The startup item created by the Portfile starts up the system bus. This one is unique for the whole system and has one known address. The other one, the session bus, is unique per session, meaning every user got his own bus. Launchd is used to manage this address like X11 does on other Linux/*NIX

Also I've included a no_x11 variant and enabled it by default (as we discussed). This alleviates any problems for those who already have this working (although the changes to how dbus-daemon is launched may cause problems initially).

I've got some concerns about that one. X11 is used, just like launchd, only to store the session bus address. Having both doesn't make sense and my break something. I would really prefer to drop it completely or at least, disable launchd when using x11. But the Portfile you've checked in seems odd to me.

Alrighty. Away it goes. See r45210.

[macsforever2000@…]

Installing this made launching gnucash worse for me. I'm seeing the issue in ticket #16755 now, whereas it was working fine for me before.

I'm on Mac OS X 10.5.6 Intel. Xcode 3.1.2. XQuartz 2.3.2.1.

[jonas.baehr@…]

Replying to macsforever2000@…:

Installing this made launching gnucash worse for me. I'm seeing the issue in ticket #16755 now, whereas it was working fine for me before.

Could you please give a bit more information? What is the error message?

Which Portfile did you tried, which variants? The Portfile originally commited by illogic-al enabled X11 and lanchd, which was not my intension (see #comment:3). In addition there are now some further changes, see r45210, r45229 and r45230.

Normally dbus autolaunch should work now for X11 and native applications if it was compiled without X11 support and your user executed launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist like the post-activation message suggests. (Under the premise that gnucash don't try a custom, non-standard autolaunch, in which case it would be a gnucash bug)

[jonas.baehr@…]

Maybe you can also find some hints in the system log using Console.app

[macsforever2000@…]

Here's my setup:

$ port installed dbus gnucash
The following ports are currently installed:
  dbus @1.2.12_1 (active)
  gnucash @2.2.8_0 (active)

I just ran the following for dbus:

$ launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist
org.freedesktop.dbus-session: Already loaded
$ launchctl unload /Library/LaunchAgents/org.freedesktop.dbus-session.plist
$ launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist

Every time I launch gnucash, I see 2 dialogs appear:

• "Cannot find default values"
• "An error occurred while loading or saving configuration information for gnucash. Some of your configuration settings may not work properly. "

Then on the command line I see the following:

$ gnucash
gnc.bin-Message: main: binreloc relocation support was disabled at configure time.

Xlib:  extension "RANDR" missing on display "/tmp/launch-5ANqZM/:0".

I'm not seeing any messages related to this in the Console.

[jonas.baehr@…]

Do you get the same error when unloading the systembus first? i.e.

$ launchctl unload /Library/LaunchAgents/org.freedesktop.dbus-session.plist
$ gnucash

At a first glance this don't seem dbus related to me (although I must say that I've absolutely no knowledge about gnome internals)

What does dbus-monitor say, with and without loading org.freedesktop.dbus-session.plist

[macsforever2000@…]

Replying to jonas.baehr@…:

Do you get the same error when unloading the systembus first? i.e.

Yes, same errors.

What does dbus-monitor say, with and without loading org.freedesktop.dbus-session.plist

With loading the plist:

signal sender=org.freedesktop.DBus -> dest=(null destination) serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.1"
   string ""
   string ":1.1"
method call sender=:1.1 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello

Without loading the plist, i can't get dbus-monitor to run at all.

$ dbus-monitor 
Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
Failed to open connection to session message bus: Not enough memory

[jonas.baehr@…]

dbus-monitor works as expected (meaning it shows the bus-traffic if the bus is present and it fails if the bus is not present)

Since you get the same gnucash errors with and without a working bus, it means either that the problem is not dbus related or, as it worked with the old x11 enabled dbus that it uses a hardcoded X11 method for finding the bus. This would be clearly a gnucash regression since the standard dbus interface for finding/connecting to the bus works (as proved by dbus-monitor). Could you ask the gnucash people about that? Maybe also pointing to this discussion here...

[macsforever2000@…]

I'm not actually a gnucash user, so i may not get around to reporting it.

[mta@…]

I get the same problem with gconf-edit, so it's not just a gnucash problem. I enabled logging in both gconf and dbus and in the log I find

 GConf-DEBUG: starting (version 2.24.0), pid 631 user 'mta' 
 Filling in system bus address... 
   used default system bus "unix:path=/opt/local/var/run/dbus/system_bus_socket" 
 Filling in session bus address... 
   "launchd:key=session,guid=1753c5538d82685d2d69b9f2496abc69" 
 Filling in activation bus address... 
   "launchd:key=session,guid=1753c5538d82685d2d69b9f2496abc69" 
 Bus activation type was set to "session" 
 opening shared connection to: launchd:key=session,guid=1753c5538d82685d2d69b9f2496abc69 
 checking for existing connection 
 creating shared_connections hash table 
   successfully created shared_connections 
 GConf-CRITICAL **: Could not connect to session bus: Could not parse server address: 
        Unknown address type (examples of valid types are "tcp" and on UNIX "unix") 

The "opening shared connection" message comes from dbus_connection_open_internal. It then calls connection_try_from_address_entry which calls _dbus_transport_open. This function loops over the elements in open_funcs trying to find one that recognizes the transport method. As far as I can tell none of them recognize a "launchd" method. There are three of them (four if DBUS_BUILD_TESTS is set) which recognize "tcp", "unix", "autolaunch", and maybe "debug-pipe".

I must be missing something since this is far too obvious. What am I doing wrong?

[mta@…]

Cc Me!

[tcwan@…]

I tried to run dbus-launch (1.2.12) in a user account:

Failed to start message bus: Check-in failed: Permission denied

EOF in dbus-launch reading address from bus daemon

$ ps ax |fgrep dbus returns: 128 ?? S 0:00.16 /opt/local/bin/dbus-daemon --nofork --session

$ launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist org.freedesktop.dbus-session: Already loaded

[meowsqueak@…]

Cc Me!

[meowsqueak@…]

Replying to tcwan@…:

I tried to run dbus-launch (1.2.12) in a user account: Failed to start message bus: Check-in failed: Permission denied EOF in dbus-launch reading address from bus daemon $ ps ax |fgrep dbus returns: 128 ?? S 0:00.16 /opt/local/bin/dbus-daemon --nofork --session $ launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist org.freedesktop.dbus-session: Already loaded

I too have this exact same problem - the above commands yield the same results and error messages. I did a fresh MacPorts install about 24 hours ago, followed by a gnucash build. I set this in variants.conf as per the GnuCash/MacPorts installation instructions:

+no_static +no_x11 -x11 +quartz

I've spent a lot of time searching for a solution and this is the first place where I've seen someone post the same error message.

Is this a new bug or does this one need re-opening?

[jonas.baehr@…]

Replying to tcwan@…:

I tried to run dbus-launch (1.2.12) in a user account: Failed to start message bus: Check-in failed: Permission denied EOF in dbus-launch reading address from bus daemon $ ps ax |fgrep dbus returns: 128 ?? S 0:00.16 /opt/local/bin/dbus-daemon --nofork --session $ launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist org.freedesktop.dbus-session: Already loaded

dbus-launch is only needed for X11 systems. There it starts up the bus, and prints the parameter to stdout. When using the --autolaunch option, it also registers the session bus address as a X11 property and sets up a babysitter process to watch and restart the bus in case of failure. All this is obsolete as now launchd starts up the session bus, plays watchdog, and manages the session bus address. Don't use dbus-launch anymore unless you know what you're doing! Normally the user should just once call launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist. Since 10.5 users can even let launchd start dbus on demand by activating it in /Library/LaunchAgents/org.freedesktop.dbus-session.plist (in 10.4 it's unfortunately broken, but that's a launchd bug)

[jonas.baehr@…]

Replying to mta@…:

I get the same problem with gconf-edit, so it's not just a gnucash problem. I enabled logging in both gconf and dbus and in the log I find {{{ GConf-DEBUG: starting (version 2.24.0), pid 631 user 'mta' Filling in system bus address... used default system bus "unix:path=/opt/local/var/run/dbus/system_bus_socket" Filling in session bus address... "launchd:key=session,guid=1753c5538d82685d2d69b9f2496abc69" Filling in activation bus address... "launchd:key=session,guid=1753c5538d82685d2d69b9f2496abc69" Bus activation type was set to "session" opening shared connection to: launchd:key=session,guid=1753c5538d82685d2d69b9f2496abc69 checking for existing connection creating shared_connections hash table successfully created shared_connections GConf-CRITICAL **: Could not connect to session bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") }}} The "opening shared connection" message comes from dbus_connection_open_internal. It then calls connection_try_from_address_entry which calls _dbus_transport_open. This function loops over the elements in open_funcs trying to find one that recognizes the transport method. As far as I can tell none of them recognize a "launchd" method. There are three of them (four if DBUS_BUILD_TESTS is set) which recognize "tcp", "unix", "autolaunch", and maybe "debug-pipe". I must be missing something since this is far too obvious. What am I doing wrong?

That's really strange. The dbus patch which this bug report is all about implements the "launchd" address type. Could you find out where the last error comes from (the GConf-CRITICAL)? If it forwards a dbus error we have to track down this problem, if gconf performs an custom dbus startup or address checking, it's a gconf bug (it works for KDE4 and dbus' own tools like dbus-monitor).

[mta@…]

That error is composed of three parts. The first part ("Could not connect to session bus") comes from get_on_d_bus in the file gconfd.c. This is in the gconf code that the process spawned by dbus uses to contact the dbus that spawned it. It just calls "dbus_bus_get (DBUS_BUS_SESSION, &bus_error)", nothing special. This message is logged if that call fails, i.e., if dbus_error_is_set (&bus_error) is true.

The second part ("Could not parse server address") comes from _dbus_set_bad_address in dbus-address.c. This has been called from _dbus_transport_open in dbus-transport.c which has been called indirectly from dbus_bus_get. This function produces the third part ("Unknown address type (examples of valid types are \"tcp\" and on UNIX \"unix\")") if the loop over open_funcs that I mentioned above fails. The address it's trying to parse is the "launchd:..." address quoted in the log snippet above.

GConf isn't doing anything non-standard, I really think this is a dbus bug, or perhaps a configuration problem, although it doesn't feel like that. It looks like there's at least one more place that needs to learn about launchd addresses.

[macsforever2000@…]

I'm re-opening this for now.

[macsforever2000@…]

I think this is a dbus problem. On a different computer (latest Mac Pro) I installed gnucash with the old dbus 1.2.10. gnucash launched fine with no problems. Then I upgraded only dbus to 1.2.12 (port revision 1) and the problem occurs. I then deactivated the newer version and activated 1.2.10 again and gnucash launches fine with no problems.

[tmdias@…]

Cc Me!

[jonas.baehr@…]

Replying to mta@…:

That error is composed of three parts. The first part ("Could not connect to session bus") comes from get_on_d_bus in the file gconfd.c. This is in the gconf code that the process spawned by dbus uses to contact the dbus that spawned it. It just calls "dbus_bus_get (DBUS_BUS_SESSION, &bus_error)", nothing special. This message is logged if that call fails, i.e., if dbus_error_is_set (&bus_error) is true. The second part ("Could not parse server address") comes from _dbus_set_bad_address in dbus-address.c. This has been called from _dbus_transport_open in dbus-transport.c which has been called indirectly from dbus_bus_get. This function produces the third part ("Unknown address type (examples of valid types are \"tcp\" and on UNIX \"unix\")") if the loop over open_funcs that I mentioned above fails. The address it's trying to parse is the "launchd:..." address quoted in the log snippet above. GConf isn't doing anything non-standard, I really think this is a dbus bug, or perhaps a configuration problem, although it doesn't feel like that. It looks like there's at least one more place that needs to learn about launchd addresses.

Hmm... dbus-monitor also does simply call dbus_but_get(DBUS_BUS_SESSION, &error) and it works... Only difference: It checks the connection, not the error, see tools/dbus-monitor.c:

  dbus_error_init (&error);
  connection = dbus_bus_get (type, &error);
  if (connection == NULL)
    {
      fprintf (stderr, "Failed to open connection to %s message bus: %s\n",
         (type == DBUS_BUS_SYSTEM) ? "system" : "session",
               error.message);
      dbus_error_free (&error);
      exit (1);
    }

I'll investigate that. I have to install gconf first though and currently gtk2 makes some trouble (i686-apple-darwin9-gcc-4.0.1: /usr/X11/lib/libXdamage.1.1.0.dylib: No such file or directory). Anyway, I'll keep you informed about the progress. If dbus_bus_get returns a connection and an error, it's a problem with the launchd patch for sure!

[meowsqueak@…]

Replying to jonas.baehr@…:

dbus-launch is only needed for X11 systems.

Ok - perhaps then if +quartz is used, then it shouldn't tell the user to launch gnucash with 'dbus-launch', because it's extremely confusing (since it doesn't work).

[olaf@…]

Cc Me!

[jonas.baehr@…]

I've got the impression that the problem is autolaunching gconfd-2 (which may be related to this dbus patch but is not necessarily a dbus bug). How do I enable gconf logging?

When using export GCONF_DEBUG_TRACE_CLIENT=1 I can see something like this in the console if dbus-deamon is running: Details - 1: Could not send message to gconf daemon: Launch helper exited with unknown return code 1. If dbus-deamon is not running, then the error is the same as with dbus-monitor: Details - 1: Failed to get connection to session: Not enough memory

gconf-editor (I did not test gnucash, but it should be the same) can't autostart gconfd-2. It works flawless if I start gconfd-2 manually by executing /opt/local/libexec/gconfd-2 and then launching gconf-editor in an other terminal. So if gconfd is running, dbus is absolutely no problem.

[meowsqueak@…]

Replying to jonas.baehr@…:

I've got the impression that the problem is autolaunching gconfd-2

I agree - I checked 'ps' and I had no 'gconfd-2' process. So I started it according to your instructions above and now GnuCash works properly. So it also looks to me as if gconfd-2 is not auto-launching.

[macsforever2000@…]

Replying to meowsqueak@…:

I agree - I checked 'ps' and I had no 'gconfd-2' process. So I started it according to your instructions above and now GnuCash works properly. So it also looks to me as if gconfd-2 is not auto-launching.

Confirmed! This allows gnucash to work properly for me too.

[olaf@…]

Replying to jonas.baehr@…:

How about the quartz version of gnucash? Gnucash is installed but gconf is not. I cannot start gnucash though. $ gnucash gnc.bin-Message: main: binreloc relocation support was disabled at configure time. (gnucash:5628): qof-CRITICAL **: qof_object_shutdown: assertion `object_is_initialized == TRUE' failed

Of course I get the usual message boxes about a wrong configuration of gnucash.

[tcwan@…]

Replying to jonas.baehr@…:

I've got the impression that the problem is autolaunching gconfd-2

[...]

gconf-editor (I did not test gnucash, but it should be the same) can't autostart gconfd-2. It works flawless if I start gconfd-2 manually by executing /opt/local/libexec/gconfd-2 and then launching gconf-editor in an other terminal. So if gconfd is running, dbus is absolutely no problem.

I tried running gconfd-2 and then gconf-editor manually, and then running gnucash. This results in gnucash hanging at the splash screen right after "Loading data...". In the terminal, it says Found Financial::Quote version 1.13. If gconfd-2 was not running, gnucash will startup with the warning about not having any configuration data, etc. and prompts to create new default configuration etc.

I've been seeing this problem where gnucash will hang at the splash screen since about 3rd Jan 2009 when there were new ports released for various X11 bits. startx would complain about older versions of X11.app, etc. I ended up having to install a new Xquartz release.

Prior to 3rd Jan 2009, dbus 1.2.10 (?) was working fine with the /var/tmp/... path listen socket (other than having to edit dbus's session.conf to convert '+' to %2b). With the 1.2.12_1 release, I only see one automatically started dbus process: '/opt/local/bin/dbus-daemon --nofork --session' running on my system.

This is on OS X Leopard 10.5.6, latest iPhone SDK (if it makes any difference), and XQuartz 2.3.2. gnucash 2.2.8_0 was compiled with the default settings (no variants selected).

[pgijnxn02@…]

Cc Me!

[mta@…]

Replying to jonas.baehr@…:

I've got the impression that the problem is autolaunching gconfd-2 (which may be related to this dbus patch but is not necessarily a dbus bug). How do I enable gconf logging?

You enable gconf logging by setting GCONF_DEBUG_OUTPUT. If you also set DBUS_VERBOSE you'll get log output like I quoted above.

gconf-editor (I did not test gnucash, but it should be the same) can't autostart gconfd-2. It works flawless if I start gconfd-2 manually by executing /opt/local/libexec/gconfd-2 and then launching gconf-editor in an other terminal. So if gconfd is running, dbus is absolutely no problem.

Isn't it dbus that starts gconfd-2? gconf-editor contacts dbus to talk to gconfd. If it isn't running dbus starts it and initiates communication between it and gconf-editor. It looks to me like the problem is that the copy of gconfd-2 started by dbus can't find the dbus session that started it.

To verify this, I stepped through the code a bit in gdb and it is clear that _dbus_transport_open is being called in the gconfd-2 process which is the grandchild of the dbus process. Since it is being called with a launchd: address and none of the functions in open_funcs can handle such an address it fails. I set a breakpoint in _dbus_transport_open in the gconfd-2 process and watched it fail. I also stepped through the code that forked this process so I know it's the process created by dbus. This sure looks like a dbus bug to me.

[jonas.baehr@…]

Replying to mta@…:

Replying to jonas.baehr@…:

I've got the impression that the problem is autolaunching gconfd-2 (which may be related to this dbus patch but is not necessarily a dbus bug). How do I enable gconf logging?

You enable gconf logging by setting GCONF_DEBUG_OUTPUT. If you also set DBUS_VERBOSE you'll get log output like I quoted above.

Thanks, I found only GCONF_DEBUG_TRACE_CLIENT. However, I get an other output. Here dbus nicely gets the socket from launchd as expected:

3673: Filling in system bus address...
3673:   used default system bus "unix:path=/opt/local/var/run/dbus/system_bus_socket"
3673: Filling in session bus address...
3674: /dev/null fd 7 opened
3673:   "unix:path=/tmp/launch-63l6Gx/session"
3673: Filling in activation bus address...
3673:   "none set"
3673: opening shared connection to: unix:path=/tmp/launch-63l6Gx/session
3673: checking for existing connection
3673: creating shared_connections hash table
3673:   successfully created shared_connections
3673: connecting to unix socket /tmp/launch-63l6Gx/session abstract=0
3673: socket fd 3 opened
3673: Successfully connected to unix socket /tmp/launch-63l6Gx/session
[...]

}}}

gconf-editor (I did not test gnucash, but it should be the same) can't autostart gconfd-2. It works flawless if I start gconfd-2 manually by executing /opt/local/libexec/gconfd-2 and then launching gconf-editor in an other terminal. So if gconfd is running, dbus is absolutely no problem.

Isn't it dbus that starts gconfd-2? gconf-editor contacts dbus to talk to gconfd. If it isn't running dbus starts it and initiates communication between it and gconf-editor. It looks to me like the problem is that the copy of gconfd-2 started by dbus can't find the dbus session that started it.

Yes, gconfd-2 should be started by the dbus server, so I think now too that there is nothing wrong with gconf. My impression is that dbus-deamon can't start gconfd-2, but I haven't figured out why... The message "Launch helper exited with unknown return code 1" commes from the dbus error.

To verify this, I stepped through the code a bit in gdb and it is clear that _dbus_transport_open is being called in the gconfd-2 process which is the grandchild of the dbus process. Since it is being called with a launchd: address and none of the functions in open_funcs can handle such an address it fails. I set a breakpoint in _dbus_transport_open in the gconfd-2 process and watched it fail. I also stepped through the code that forked this process so I know it's the process created by dbus. This sure looks like a dbus bug to me.

Yes, it looks like. But the question is: why every dbus-app can find the bus via launchd, expect gconfd-2 if stated by dbus-deamon. If it's stated manually, it works too.

[mta@…]

Is the log snippet you quote from a case where dbus launched gconfd-2 or was it already running? I presume it was already running.

If dbus launches it, then gconfd-2 gets the service address from the environment variable DBUS_SESSION_BUS_ADDRESS. This is set in add_bus_environment which is called from bus_activation_activate_service before it launches gconfd-2. The value for DBUS_SESSION_BUS_ADDRESS is taken from activation->server_address from the activation struct passed to bus_activation_activate_service. This is a "launchd:..." type address. The real question is should it be this type of address or should it be a "unix:..." style address. I.e., is the bug in the creation of the activation struct or is it that there needs to be a handler added to open_funcs in dbus-transport.c for the "launchd:..." address that's in it.

[jonas.baehr@…]

Replying to mta@…:

Is the log snippet you quote from a case where dbus launched gconfd-2 or was it already running? I presume it was already running.

Sorry, I messed up server and client here. gconfd-2 was not running, but the log snipped is from gconf-editor, not gfoncd-2.

If dbus launches it, then gconfd-2 gets the service address from the environment variable DBUS_SESSION_BUS_ADDRESS. This is set in add_bus_environment which is called from bus_activation_activate_service before it launches gconfd-2. The value for DBUS_SESSION_BUS_ADDRESS is taken from activation->server_address from the activation struct passed to bus_activation_activate_service. This is a "launchd:..." type address. The real question is should it be this type of address or should it be a "unix:..." style address. I.e., is the bug in the creation of the activation struct or is it that there needs to be a handler added to open_funcs in dbus-transport.c for the "launchd:..." address that's in it.

Now we're comming nearer! In fact, the DBUS_SESSION_BUS_ADDRESS evn-var is treated with priority, to that one can always override launchd. However, if it's not present, then launchd is asked. That's why it works when starting gconfd-2 manually (assuming there is no env-var). If the client has such an env-var set, it's the correct behaviour to pass it to the newly starting service.

I think the solution is to ask launchd for the address if DBUS_SESSION_BUS_ADDRESS is not set, or it contains a launchd: address. The latter is currently not the case. I'll fix that.

Thanks a lot for your analysis!

[mta@…]

Replying to jonas.baehr@…:

I think the solution is to ask launchd for the address if DBUS_SESSION_BUS_ADDRESS is not set, or it contains a launchd: address. The latter is currently not the case. I'll fix that.

It's not clear to me that it's that simple, although I don't understand this code well enough to be sure. The "launchd:..." address comes from _dbus_server_new_for_socket which constructs it from the string "launchd:key=session" passed to it from _dbus_server_listen_platform_specific and a guid created and appended by _dbus_server_init_base. Then this is passed, via the DBUS_SESSION_BUS_ADDRESS environment variable, to the child configd-2 process. It's not obvious that having that child process get the DBUS_LAUNCHD_SESSION_BUS_SOCKET from launchctl will return the correct socket name. What's the guid good for? Should it be used some way to look up the socket? Should the server be doing this and assigning the correct Unix socket name to DBUS_SESSION_BUS_ADDRESS? It's questions like this which kept me from implementing a fix.

[vinc17@…]

Cc Me!

[jonas.baehr@…]

Replying to mta@…:

Replying to jonas.baehr@…:

I think the solution is to ask launchd for the address if DBUS_SESSION_BUS_ADDRESS is not set, or it contains a launchd: address. The latter is currently not the case. I'll fix that.

It's not clear to me that it's that simple, although I don't understand this code well enough to be sure. The "launchd:..." address comes from _dbus_server_new_for_socket which constructs it from the string "launchd:key=session" passed to it from _dbus_server_listen_platform_specific and a guid created and appended by _dbus_server_init_base. Then this is passed, via the DBUS_SESSION_BUS_ADDRESS environment variable, to the child configd-2 process. It's not obvious that having that child process get the DBUS_LAUNCHD_SESSION_BUS_SOCKET from launchctl will return the correct socket name. What's the guid good for? Should it be used some way to look up the socket? Should the server be doing this and assigning the correct Unix socket name to DBUS_SESSION_BUS_ADDRESS? It's questions like this which kept me from implementing a fix.

The code you mention is to spawn a server (a dbus-daemon instance), not to get the bus address from within the client. gconfd-2 is a dbus client though. Look at init_session_address in dbus-bus.c to find the behaviour I described. A platform-specific look-up is only performed is DBUS_SESSION_BUS_ADDRESS is not set.

I'm not sure which is the best approach to fix it. In fact, launchd: is not a real address type, but rather an address lookup method. So, with this in mind it might be a solution to pass the real unix:path=/foo address to _dbus_server_new_for_socket (in dbus-server-launchd.c). However, something like this

DBUS_SESSION_BUS_ADDRESS="launchd:key=session" dbus-monitor

won't work with it... (That's exactly the problem gconfd-2 has, when autolaunched by dbus-daemon) The question is now if we want launchd to behave like a real address type, or if it's just a lookup/pseudo-adress only valid in a server config file.

Since it does not make sense to lookup the same address again I'd say one should set the server's address to unix:path instead of reconstructing the original launchd address, which is then used again in the client to lookup the socket. This doesn't feel right and should fix our gconfd-2 problem (every autolaunched service, in fact). Accepting launchd: addresses in DBUS_SESSION_BUS_ADDRESS can be a second step.

[clubjuggler@…]

Cc Me!

[mta@…]

Replying to jonas.baehr@…:

The code you mention is to spawn a server (a dbus-daemon instance), not to get the bus address from within the client. gconfd-2 is a dbus client though. Look at init_session_address in dbus-bus.c to find the behaviour I described. A platform-specific look-up is only performed is DBUS_SESSION_BUS_ADDRESS is not set.

Yes, I realize that. The server that is spawned then has to find a socket to talk to the dbus that spawned it. This is the code that is constructing the value for the environment variable that will be used by the spawned server (gconfd-2) to find this socket. I think this is what you are saying too.

I'm not sure which is the best approach to fix it. In fact, launchd: is not a real address type, but rather an address lookup method. So, with this in mind it might be a solution to pass the real unix:path=/foo address to _dbus_server_new_for_socket (in dbus-server-launchd.c). However, something like this

DBUS_SESSION_BUS_ADDRESS="launchd:key=session" dbus-monitor

won't work with it... (That's exactly the problem gconfd-2 has, when autolaunched by dbus-daemon) The question is now if we want launchd to behave like a real address type, or if it's just a lookup/pseudo-adress only valid in a server config file. Since it does not make sense to lookup the same address again I'd say one should set the server's address to unix:path instead of reconstructing the original launchd address, which is then used again in the client to lookup the socket. This doesn't feel right and should fix our gconfd-2 problem (every autolaunched service, in fact). Accepting launchd: addresses in DBUS_SESSION_BUS_ADDRESS can be a second step.

I agree that something like this is probably the best solution. I suppose you could do both, change the address passed to spawned clients and also accept a launchd: address passed back, but this doesn't seem either necessary or right.

[jonas.baehr@…]

I've got a solution, not a perfect one though. The dbus-daemon get's only a file descriptor from launchd, not an unix path. The path can only be retrieved by querying launchd's envorinment. Here, the env-var is not the same as the key as for lookup the fd. Here is a hot fix which should be fine for 99.9% of the users.

diff --git a/dbus/dbus-server-launchd.c b/dbus/dbus-server-launchd.c
index 1ede3cc..6bb8575 100644
--- a/dbus/dbus-server-launchd.c
+++ b/dbus/dbus-server-launchd.c
@@ -71,12 +71,12 @@ _dbus_server_new_for_launchd_key (const char *socket_key,
       dbus_set_error (error, DBUS_ERROR_NO_MEMORY, NULL);
       return NULL;
     }
-  if (!_dbus_string_append (&address, "launchd:key="))
+  if (!_dbus_string_append (&address, "unix:path="))
     {
       dbus_set_error (error, DBUS_ERROR_NO_MEMORY, NULL);
       goto l_failed_0;
     }
-  if (!_dbus_string_append (&address, socket_key))
+  if (!_dbus_string_append (&address, _dbus_getenv("DBUS_LAUNCHD_SESSION_BUS_SOCKET")))
     {
       dbus_set_error (error, DBUS_ERROR_NO_MEMORY, NULL);
       goto l_failed_0;

It has several problems though:

• It allways assume the session bus. (no mapping from socket_key to env-var)
• It works only if dbus-daemon is started by launchd. (else the env-var is simply not present)

To make it short everything non-standard will not work: Custom busses and manual started dbus-daemons can't autolaunch services when using launchd-addresses. This are corner cases so in my eyes this patch can be used for our Portfile (for now) but for  dbus upstream I have to think about something better...

[tommyd@…]

Cc Me!

[mta@…]

That's more or less the patch I had in mind. I came up with a slightly different version which I'll attach. The main differences are that _dbus_server_new_for_launchd_fd uses _dbus_lookup_session_address to get the socket address. This means that it calls launchctl to get the address instead of depending on the environment variable being set. This may or may not be a good idea, but it will make it work in some cases when it wouldn't otherwise.

I also added code to allow clients to use launchd:... addresses by adding a new function _dbus_transport_open_launchd to the open_funcs table in dbus-transport.c. This means that you can set DBUS_SESSION_BUS_ADDRESS to "launchd:key=server" and start a client and it will work in any process that is a child of the launchd process that started dbus-daemon. This may or may not be useful, but it seemed like a good idea.

Custom buses and manually started dbus-daemons work if you give them a different configuration file. If you use the standard one it will try to use the same socket as the dbus-daemon started by launchd which probably won't work no matter what we do. I have a periodic task started by the root launchd (but running under my ID) that starts a private dbus. This seems to work fine.

[mta@…]

Patch for changes to launchd support.

[jonas.baehr@…]

Replying to mta@…:

That's more or less the patch I had in mind. I came up with a slightly different version which I'll attach. The main differences are that _dbus_server_new_for_launchd_fd uses _dbus_lookup_session_address to get the socket address. This means that it calls launchctl to get the address instead of depending on the environment variable being set. This may or may not be a good idea, but it will make it work in some cases when it wouldn't otherwise.

That's cleaner, yes. A final version of the launchd patch will certainly go in this direction. However, simply looking up the session bus address has the same problem as my hot-fix above: It works only for the session bus. Your patch should also work with dbus-daemons not spawned by launchd since it doesn't relies on the env-var, but that's the only benefit.

I also added code to allow clients to use launchd:... addresses by adding a new function _dbus_transport_open_launchd to the open_funcs table in dbus-transport.c. This means that you can set DBUS_SESSION_BUS_ADDRESS to "launchd:key=server" and start a client and it will work in any process that is a child of the launchd process that started dbus-daemon. This may or may not be useful, but it seemed like a good idea.

With the extension to _dbus_server_new_for_launchd_fd any child will already get a native adress. To allow real launchd addresses in any context (the original patch supports them only for spawning a server) we need some kind of mapping between the socket key (used to get the file descriptor for the server) and the env-var, used to lookup the unix path to the socket. It doesn't seem possible to lookup both only the the key.

Custom buses and manually started dbus-daemons work if you give them a different configuration file. If you use the standard one it will try to use the same socket as the dbus-daemon started by launchd which probably won't work no matter what we do. I have a periodic task started by the root launchd (but running under my ID) that starts a private dbus. This seems to work fine.

Here I can't follow. Your patch throws an error if the key is not "session". How should that work with custom busses?

[jonas.baehr@…]

New version of the dbus patch, now everything should work

[jonas.baehr@…]

I've got it. Now auto launching of services works, as well as custom busses and launchd-type addresses for client connections.

I changed the syntax of launchd addresses a bit. Now it has the form "launchd:env=MY_FOO_ENV_VAR". The key used in the previous version is completely useless as it has to be always the same. My hotfix in #comment:42 is also valid, since only children of launchd can talk to launchd via IPC. That means the env var is always present, but also that it's impossible to start dbud-daemon manually if it should listen on a "launchd:"-address. This limitation lays in the design of launchd and is not a problem with the patch.

Using "launchd:"-addresses on the client side was implemented in dbus-transport-unix.c in _dbus_transport_open_platform_specific as a supplement to the "unix:" method. This way fits the best with the rest of the code.

Please test. I think this ticket can be closed since the new version of the patch should solve all of the above issues.

[macsforever2000@…]

Please post a universal diff of the portfile. There was at least one mistake in your new portfile, the revision should be set to 4 but yours had no revision. I noticed you removed the darwin 7 specific fixes - will this new version work in Panther?

[blb@…]

Replying to macsforever2000@…:

Please post a universal diff of the portfile. There was at least one mistake in your new portfile, the revision should be set to 4 but yours had no revision. I noticed you removed the darwin 7 specific fixes - will this new version work in Panther?

launchd was introduced in 10.4 so anything specific to that is quite unlikely to work on 10.3; so this should probably be enabled in a platform darwin section and testing for 10.4 or later (see for example the cairo port, in the platform macosx section). Then all other situations should be covered by the default dbus configuration.

[mta@…]

Replying to jonas.baehr@…:

My hotfix in #comment:42 is also valid, since only children of launchd can talk to launchd via IPC. That means the env var is always present, but also that it's impossible to start dbud-daemon manually if it should listen on a "launchd:"-address. This limitation lays in the design of launchd and is not a problem with the patch.

I don't think this is quite right. There is a tree of processes under launchd. Any process in this tree can talk to launchd and get the value of the environment variable using code like that in _dbus_lookup_session_address_launchd. However the environment variable itself is only in the environment of the dbus process and its descendants. I don't know if this matters much, but it means that clients started by siblings or cousins of the dbus process don't have the environment variable giving the dbus socket in their environment.

When I logon the dbus process gets started. If I subsequently start (for example) a terminal process from which I start a dbus client, it can't find the dbus started by launchd unless it uses code like that in _dbus_lookup_session_address_launchd.

Please test. I think this ticket can be closed since the new version of the patch should solve all of the above issues.

I suspect it works for most of the cases that matter. I'll give it a try and get back to you.

[mta@…]

Replying to jonas.baehr@…:

I've got it. Now auto launching of services works, as well as custom busses and launchd-type addresses for client connections.

This patch seems to work fine. I got it to work with a private bus started by launchd and a private bus I started manually as well as with the default bus.

It would be nice to include a "platform darwin 9" section in the port file that sets OnDemand to true in the launchd plist, but that's not really necessary.

[jonas.baehr@…]

Replying to macsforever2000@…:

Please post a universal diff of the portfile. There was at least one mistake in your new portfile, the revision should be set to 4 but yours had no revision. I noticed you removed the darwin 7 specific fixes - will this new version work in Panther?

Sorry, my mistake. I used the same Portfile as in the initial comment, but in fact only the patch has changed. So, it should be fine to keep the current Portfile from svn and just replace the patch. The svn Portfile should already cover darwin7 and universal builds.

[jonas.baehr@…]

Replying to mta@…:

Replying to jonas.baehr@…:

My hotfix in #comment:42 is also valid, since only children of launchd can talk to launchd via IPC. That means the env var is always present, but also that it's impossible to start dbud-daemon manually if it should listen on a "launchd:"-address. This limitation lays in the design of launchd and is not a problem with the patch.

I don't think this is quite right. There is a tree of processes under launchd. Any process in this tree can talk to launchd and get the value of the environment variable using code like that in _dbus_lookup_session_address_launchd. However the environment variable itself is only in the environment of the dbus process and its descendants. I don't know if this matters much, but it means that clients started by siblings or cousins of the dbus process don't have the environment variable giving the dbus socket in their environment.

The environment variable can be accessed by any process of your user using the launchctl getenv FOO method. This is what all the clients do. The server however needs the file descriptor of the socket so listen on, and that one can only be accessed if it was spawned by launchd itself. Under this condition the server has also access to the envorinment variable directly, which he uses to pass the socket path on which we listens to it's childs (autolaunched services)

When I logon the dbus process gets started. If I subsequently start (for example) a terminal process from which I start a dbus client, it can't find the dbus started by launchd unless it uses code like that in _dbus_lookup_session_address_launchd.

As I said, the client never did anything else then asking via launchctl. I just recaftored the code a bit to share it between the dynamic session bus lookup and the resolving "launch:" addresses.

[macsforever2000@…]

Committed revision r45725. This version finally works for me. Thanks! Let's wait for some feedback before closing this ticket though.

[mta@…]

Replying to jonas.baehr@…:

As I said, the client never did anything else then asking via launchctl. I just recaftored the code a bit to share it between the dynamic session bus lookup and the resolving "launch:" addresses.

Right, after I took a look at your code I realized that's what you did. The new version looks fine to me. Thanks for working on this.

[tmdias@…]

Replying to macsforever2000@…:

Committed revision r45725. This version finally works for me. Thanks! Let's wait for some feedback before closing this ticket though.

Thumbs up on Tiger/PPC. Both planner and gnucash work peacefully. Thanks!

[kadorken@…]

Replying to macsforever2000@…:

Committed revision r45725. This version finally works for me. Thanks! Let's wait for some feedback before closing this ticket though.

Well I was having the same problems as in  http://trac.macports.org/ticket/16755 after switching from (a working) X11 version of gnucash 2.2.28 to the quartz version (using the instructions found in  http://wiki.gnucash.org/wiki/MacOSX/MacPortsDetail to first uninstall the X11 version $ sudo port uninstall --follow-dependents cairo $ sudo port uninstall --follow-dependents dbus ), then reinstalling gnucash with the changes to /opt/local/etc/macports/variants.conf and add the following four lines: +no_static +no_x11 -x11 +quartz

---

I did this just before the  http://trac.macports.org/changeset/45725 was posted above; I encountered the problems outlined in [ http://trac.macports.org/ticket/16755]. This was with dbus @1.2.12_3;

I then found this thread and did an 'upgrade' to dbus to @1.2.12_4 (confirmed as active), but my original problem still exists.

I am running MAC OS 10.5.6 (IMAC INTEL CORE 2)

Perhaps I need to completely blow away macports and try anew. At the moment, I am reverting (hopefully) back to the X11 variant. [UPDATE: x11 variant just rebuilt, but my problems now remain; it appears to be a something to do with GCONF so I'm going to blow everything away and start over]

[vinc17@…]

First the fact that it does not work is a bug, not a RFE (otherwise bug 18002 should not have been marked as a duplicate).

The current dbus version (1.2.12_4) crashes:

Date/Time:      2009-01-21 12:46:37.769 +0100
OS Version:     10.4.11 (Build 8S165)
Report Version: 4

Command: dbus-daemon
Path:    /opt/local/bin/dbus-daemon
Parent:  dbus-launch [12213]

Version: ??? (???)

PID:    12214
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   dbus-daemon 	0x00044fc0 _dbus_server_new_for_launchd + 32
1   dbus-daemon 	0x00040348 _dbus_server_listen_platform_specific + 664
2   dbus-daemon 	0x000307d8 dbus_server_listen + 392
3   dbus-daemon 	0x0000558c bus_context_new + 588
4   dbus-daemon 	0x00016a78 main + 1528
5   dbus-daemon 	0x0000272c _start + 760
6   dbus-daemon 	0x00002430 start + 48

Thread 0 crashed with PPC Thread State 64:
  srr0: 0x0000000000044fc0 srr1: 0x100000000000d030                        vrsave: 0x0000000000000000
    cr: 0x48008222          xer: 0x0000000020000000   lr: 0x0000000000044fc0  ctr: 0x000000000000001f
    r0: 0x0000000000044fc0   r1: 0x00000000bfffde40   r2: 0x000000000000005f   r3: 0x0000000000000000
    r4: 0x00000000a0010260   r5: 0xfffffffffefefeff   r6: 0xffffffff80808080   r7: 0x0000000000000000
    r8: 0x0000000000000000   r9: 0x0000000000000001  r10: 0x000000000000001f  r11: 0x00000000bfffe42c
   r12: 0x0000000090002d68  r13: 0x0000000000000000  r14: 0x0000000000046494  r15: 0x0000000000046494
   r16: 0x0000000000046494  r17: 0x00000000bfffdf94  r18: 0x0000000000000000  r19: 0x0000000000050664
   r20: 0x0000000000300df0  r21: 0x0000000000051508  r22: 0x0000000000000000  r23: 0x0000000000000000
   r24: 0x0000000000000000  r25: 0x00000000bfffdf88  r26: 0x00000000bfffdfa4  r27: 0x00000000bfffdfa4
   r28: 0x0000000000000000  r29: 0x000000000004f690  r30: 0x000000000004f688  r31: 0x0000000000044fb0

Binary Images Description:
    0x1000 -    0x50fff dbus-daemon 	/opt/local/bin/dbus-daemon
   0x63000 -    0x81fff libexpat.1.dylib 	/opt/local/lib/libexpat.1.dylib
0x8fe00000 - 0x8fe52fff dyld 46.16	/usr/lib/dyld
0x90000000 - 0x901bcfff libSystem.B.dylib 	/usr/lib/libSystem.B.dylib
0x90214000 - 0x90219fff libmathCommon.A.dylib 	/usr/lib/system/libmathCommon.A.dylib
0x91433000 - 0x9143efff libgcc_s.1.dylib 	/usr/lib/libgcc_s.1.dylib

Model: PowerMac7,3, BootROM 5.2.4f1, 2 processors, PowerPC G5  (3.1), 2.7 GHz, 1.5 GB
Graphics: ATI Radeon 9650, ATY,RV351, AGP, 256 MB
Memory Module: DIMM0/J11, 256 MB, DDR SDRAM, PC3200U-30330
Memory Module: DIMM1/J12, 256 MB, DDR SDRAM, PC3200U-30330
Memory Module: DIMM2/J13, 512 MB, DDR SDRAM, PC3200U-30330
Memory Module: DIMM3/J14, 512 MB, DDR SDRAM, PC3200U-30330
Network Service: Ethernet intégré, Ethernet, en0
PCI Card: AlchemyTV, tv-card, SLOT-3
Serial ATA Device: Maxtor 6B250S0, 233.76 GB
Parallel ATA Device: PIONEER DVD-RW  DVR-109
USB Device: Hub in Apple Pro Keyboard, Mitsumi Electric, Up to 12 Mb/sec, 500 mA
USB Device: USB-PS/2 Optical Mouse, Logitech, Up to 1.5 Mb/sec, 100 mA
USB Device: Apple Pro Keyboard, Mitsumi Electric, Up to 12 Mb/sec, 250 mA

Always reproducible.

[jonas@…]

Replying to vinc17@…:

Unfortunately I can't reproduce it, nor do I have acces to a G5. Could you please try this patch:

diff --git a/dbus/dbus-server-launchd.c b/dbus/dbus-server-launchd.c
index 8bf440a..9248d27 100644
--- a/dbus/dbus-server-launchd.c
+++ b/dbus/dbus-server-launchd.c
@@ -69,7 +69,9 @@ _dbus_server_new_for_launchd (const char *launchd_env_var,
   launch_data_t sockets_dict, checkin_response;
   launch_data_t checkin_request;
   launch_data_t listening_fd_array, listening_fd;
+  _dbus_warn("== value of launchd_env_var: '%s'\n", launchd_env_var);
   const char * launchd_socket_path = _dbus_getenv(launchd_env_var);
+  _dbus_warn("== value of launchd_socket_path: '%s'\n", launchd_socket_path);
 
   _DBUS_ASSERT_ERROR_IS_CLEAR (error);
 

Then tell me please what it outputs via syslog (using Console.app) when you load the .plist

launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist (you may have to unload first)

[jonas@…]

Replying to kadorken@…:

I then found this thread and did an 'upgrade' to dbus to @1.2.12_4 (confirmed as active), but my original problem still exists.

Can't reproduce. I just installed gnucash and it just works with dbus@1.2.12_4. Did you execute this after the installation of dbus?

launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist

[mta@…]

Replying to jonas@…:

Replying to vinc17@…: Unfortunately I can't reproduce it, nor do I have acces to a G5.

I did all my testing on a G5 running Leopard. I assume this crash implies that launchd isn't setting the environment variables you need in 10.4. Perhaps the lanuchd change needs to be made a Leopard-only feature. There were a lot of fixes to launchd in Leopard.

[jonas@…]

Replying to mta@…:

I did all my testing on a G5 running Leopard. I assume this crash implies that launchd isn't setting the environment variables you need in 10.4. Perhaps the lanuchd change needs to be made a Leopard-only feature. There were a lot of fixes to launchd in Leopard.

Yes, I've read everywhere that launch agents have many problems on 10.4 but without details. Anyway, don't let's give up that fast ;-) vinc17, could you please test this patch:

diff --git a/dbus/dbus-server-launchd.c b/dbus/dbus-server-launchd.c
index 8bf440a..ee8927b 100644
--- a/dbus/dbus-server-launchd.c
+++ b/dbus/dbus-server-launchd.c
@@ -39,6 +39,7 @@
 #include <errno.h>
 
 #include "dbus-server-socket.h"
+#include "dbus-sysdeps-unix.h"
 
 /* put other private launchd functions here */
 
@@ -73,7 +74,16 @@ _dbus_server_new_for_launchd (const char *launchd_env_var,
 
   _DBUS_ASSERT_ERROR_IS_CLEAR (error);
 
-  if (*launchd_socket_path == '\0')
+  /* launchd on Mac OS X 10.4 doesn't set the env var for its children
+   * so we try to get it via launchctl
+   */
+  if (launchd_socket_path == NULL)
+    {
+      launchd_socket_path = _dbus_lookup_launchd_socket (launchd_env_var, error);
+      if (dbus_error_is_set(error))
+        return NULL;
+    }
+  if (launchd_socket_path == NULL || *launchd_socket_path == '\0')
     {
       dbus_set_error (error, DBUS_ERROR_BAD_ADDRESS,
                       "launchd's environment variable %s is empty, but should contain a socket path");

If mta's assumption is true, that should solve your problem.

[kadorken@…]

Replying to jonas@…:

Replying to kadorken@…:

I then found this thread and did an 'upgrade' to dbus to @1.2.12_4 (confirmed as active), but my original problem still exists.

Can't reproduce. I just installed gnucash and it just works with dbus@1.2.12_4. Did you execute this after the installation of dbus? {{{ launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist }}}

After removing ALL of macports, and then installing gnucash from scratch (with one glitch reported as a comment at  https://trac.macports.org/ticket/18138#comment:2), gnucash was installed. I received the message (after modifying .profile to have eval dbus-launch --auto-syntax

$ source .profile Failed to start message bus: Check-in failed: Permission denied

EOF in dbus-launch reading address from bus daemon

I then modified .profile to first do launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist

I then received the following:

$ source .profile org.freedesktop.dbus-session: Already loaded Failed to start message bus: Check-in failed: Permission denied

EOF in dbus-launch reading address from bus daemon

$ port info dbus

dbus @1.2.12, Revision 4 (devel) Variants: darwin_7, test, universal

a PS shows

501 158 154 0 31 0 75852 256 - S ?? 0:02.34 kadorken 0.0 0.0 9:15pm /opt/local/bin/dbus-daemon --nofork --session PATH=/usr/bin:/bin:/usr/sbin:/sbin TMPDIR=/var/folders/o2/o2G2VCZsEr4yO97IVJ+cpU+++TI/-Tmp-/ SHELL=/bin/bash HOME=/Users/kadorken USER=kadorken LOGNAME=kadorken LAUNCHD_FD=15 DISPLAY=/tmp/launch-Ih2MVH/:0 SSH_AUTH_SOCK=/tmp/launch-utu1fq/Listeners Apple_PubSub_Socket_Render=/tmp/launch-4iWANk/Render DBUS_LAUNCHD_SESSION_BUS_SOCKET=/tmp/launch-pFyVtI/session

running as 'me'; Is it supposed to be running as root?

[kadorken@…]

Replying to kadorken@…:

Replying to jonas@…:

Replying to kadorken@…:

I then found this thread and did an 'upgrade' to dbus to @1.2.12_4 (confirmed as active), but my original problem still exists.

Can't reproduce. I just installed gnucash and it just works with dbus@1.2.12_4. Did you execute this after the installation of dbus? {{{ launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist }}}

After removing ALL of macports, and then installing gnucash from scratch (with one glitch reported as a comment at  https://trac.macports.org/ticket/18138#comment:2), gnucash was installed. I received the message (after modifying .profile to have eval dbus-launch --auto-syntax $ source .profile Failed to start message bus: Check-in failed: Permission denied EOF in dbus-launch reading address from bus daemon I then modified .profile to first do launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist I then received the following: $ source .profile org.freedesktop.dbus-session: Already loaded Failed to start message bus: Check-in failed: Permission denied EOF in dbus-launch reading address from bus daemon $ port info dbus dbus @1.2.12, Revision 4 (devel) Variants: darwin_7, test, universal a PS shows 501 158 154 0 31 0 75852 256 - S ?? 0:02.34 kadorken 0.0 0.0 9:15pm /opt/local/bin/dbus-daemon --nofork --session PATH=/usr/bin:/bin:/usr/sbin:/sbin TMPDIR=/var/folders/o2/o2G2VCZsEr4yO97IVJ+cpU+++TI/-Tmp-/ SHELL=/bin/bash HOME=/Users/kadorken USER=kadorken LOGNAME=kadorken LAUNCHD_FD=15 DISPLAY=/tmp/launch-Ih2MVH/:0 SSH_AUTH_SOCK=/tmp/launch-utu1fq/Listeners Apple_PubSub_Socket_Render=/tmp/launch-4iWANk/Render DBUS_LAUNCHD_SESSION_BUS_SOCKET=/tmp/launch-pFyVtI/session running as 'me'; Is it supposed to be running as root?

Okay, after posting all the above, I continued to experiment (within the same terminal session that I had removed Macports, and reinstalled gnucash). I did a launchctl unload /Library/LaunchAgents/org.freedesktop.dbus-session.plist

(no error received). A PS confirmed it wasn't running. I then tried a sudo launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist (despite the warning not to do this). This resulted in

gnc.bin-Message: main: binreloc relocation support was disabled at configure time.

Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!

So I did a sudo unload ...., followed by (from the $ prompt) launchctl load .....

NOW gnucash starts up.

My theory is that all my previous attempts earlier this morning left the 'old' dbus running (?) despite me rebuilding gnucash TWICE.

I figured I should post the entire outcome in case someone else ends up doing something similar and starts searching for the various error messages.

Thanks for your assistance.

[vinc17@…]

Replying to jonas@…:

vinc17, could you please test this patch:

dbus no longer crashes. When I run liferea, I get:

Failed to start message bus: Check-in failed: Permission denied

EOF in dbus-launch reading address from bus daemon

Except from these messages (I don't know whether they are normal or not), there does not seem to be any problem.

BTW, what should be done in the ports to make sure that dbus-session is loaded?

[tcwan@…]

The latest dbus@1.2.12_4 seems to have solved all the previous problems. gnucash@2.2.8_0 is now running fine. (It took several rebuilds and clean reinstalling of MacPorts to get to this point, though I'm not sure how much of it was due to earlier builds of dbus vs. leftover configuration issues).

[olaf@…]

Replying to tcwan@…:

The latest dbus@1.2.12_4 seems to have solved all the previous problems. gnucash@2.2.8_0 is now running fine. (It took several rebuilds and clean reinstalling of MacPorts to get to this point, though I'm not sure how much of it was due to earlier builds of dbus vs. leftover configuration issues).

While I have the same result for the X supporting version of gnucash the quartz version still does not run. I've done a clean macports install but now I still get

$ eval dbus-launch --auto-syntax
EOF in dbus-launch reading address from bus daemon

[kadorken@…]

Replying to olaf@…:

Replying to tcwan@…:

The latest dbus@1.2.12_4 seems to have solved all the previous problems. gnucash@2.2.8_0 is now running fine. (It took several rebuilds and clean reinstalling of MacPorts to get to this point, though I'm not sure how much of it was due to earlier builds of dbus vs. leftover configuration issues).

While I have the same result for the X supporting version of gnucash the quartz version still does not run. I've done a clean macports install but now I still get {{{ $ eval dbus-launch --auto-syntax EOF in dbus-launch reading address from bus daemon }}}

Based on my experiences (see above), try running

launchctl list' | grep freedesktop

to see if it is launched; if nothing shows up, then do

launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist

If it looked like org.freedesktop... was running and you were getting the error, try doing

launchctl unload /Library/LaunchAgents/org.freedesktop.dbus-session.plist

, followed by a (as YOU, not sudo)

launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plis

[jonas@…]

Don't use dbus-launch! It has become obsolete since launchd is now responsible of launching the bus. This has already pointed out in #comment:18. Please read the discussion before posting the same error over and over again.

Where did you get the information from to put eval dbus-launch --auto-syntax in your .profile? This source has to be modified since it's just outdated. (well, and even without launchd support this is not recommended unless you've got a permanent X11 window open and build with dbus with x11 support. Else you will end up in having one independent session bus per Terminal session and no app will see the others)

[kadorken@…]

Replying to jonas@…:

Don't use dbus-launch! It has become obsolete since launchd is now responsible of launching the bus. This has already pointed out in #comment:18. Please read the discussion before posting the same error over and over again. Where did you get the information from to put eval dbus-launch --auto-syntax in your .profile? This source has to be modified since it's just outdated. (well, and even without launchd support this is not recommended unless you've got a permanent X11 window open and build with dbus with x11 support. Else you will end up in having one independent session bus per Terminal session and no app will see the others)

At the end of the gnucash 2.2.8_0+no_x11 install, the following is displayed:

---> Building gnucash
---> Staging gnucash into destroot
---> Installing gnucash @2.2.8_0+no_x11
---> Activating gnucash @2.2.8_0+no_x11
Warning: When you run gnucash, if it pops up a window saying:
Warning: An error occurred while loading or saving configuration
Warning: information for gnucash.
Warning: it is probably because it cannot connect to
Warning: the DBus server. Either place the following in your login
Warning: shell profile:
Warning: eval dbus-launch --auto-syntax
Warning: or invoke gnucash via 'dbus-launch gnucash'. Note that with
Warning: the latter alternative you may end up with a stray dbus
Warning: process after you quit gnucash.

This may be the source of the confusion; I'll try to figure out how to report the problem to the gnucash side so the install of gnucash is updated.

[kadorken@…]

Replying to kadorken@…:

This may be the source of the confusion; I'll try to figure out how to report the problem to the gnucash side so the install of gnucash is updated.

I have posted a ticket regarding the warning at  https://trac.macports.org/ticket/18155

[olaf@…]

Replying to jonas@…:

Don't use dbus-launch! It has become obsolete since launchd is now responsible of launching the bus. This has already pointed out in #comment:18. Please read the discussion before posting the same error over and over again.

O.k., my fault, this was the wrong example. In fact the quartz variant of gnucash shows the error of not finding configuration settings when it starts. It's a clean rebuilt of macports and I've tried all the hints mentioned above. Is here anyone who has a quartz variant of gnucash up and running?

[kadorken@…]

Replying to olaf@…:

Replying to jonas@…:

Don't use dbus-launch! It has become obsolete since launchd is now responsible of launching the bus. This has already pointed out in #comment:18. Please read the discussion before posting the same error over and over again.

O.k., my fault, this was the wrong example. In fact the quartz variant of gnucash shows the error of not finding configuration settings when it starts. It's a clean rebuilt of macports and I've tried all the hints mentioned above. Is here anyone who has a quartz variant of gnucash up and running?

Yes; I have gnucash 2.2.8 running now under quartz; it starts fine after restarting macos with no special handling. There are no entries in my .profile (all commented out) wrt dbus. If you do a
launchctl list | grep freedesktop
do you find anything? (I think you should because if not, then dbus-session will not be running for you after a restart; this is supposition on my part as I slowly figure out the ins/outs of operating under Macos)

[vinc17@…]

Replying to jonas@…:

Don't use dbus-launch! It has become obsolete since launchd is now responsible of launching the bus.

Liferea does:

if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
        eval `dbus-launch`
        export DBUS_SESSION_BUS_ADDRESS
fi

If this is a problem, dbus-launch should be symlinked to /usr/bin/true. And how can Liferea get the bus address?

[olaf@…]

Replying to kadorken@…:

Yes; I have gnucash 2.2.8 running now under quartz; it starts fine after restarting macos with no special handling. There are no entries in my .profile (all commented out) wrt dbus. If you do a
launchctl list | grep freedesktop
do you find anything? (I think you should because if not, then dbus-session will not be running for you after a restart; this is supposition on my part as I slowly figure out the ins/outs of operating under Macos)

$ launchctl list | grep freedesktop
org.freedesktop.dbus-session
$ sudo launchctl list | grep dbus
org.macports.dbus
$ gnucash
gnc.bin-Message: main: binreloc relocation support was disabled at configure time.


(gnucash:4817): qof-CRITICAL **: qof_object_shutdown: assertion `object_is_initialized == TRUE' failed

Of course after the start of gnucash two messageboxes appear.

[kadorken@…]

Replying to olaf@…:

{{{ $ launchctl list | grep freedesktop org.freedesktop.dbus-session $ sudo launchctl list | grep dbus org.macports.dbus $ gnucash gnc.bin-Message: main: binreloc relocation support was disabled at configure time. (gnucash:4817): qof-CRITICAL **: qof_object_shutdown: assertion `object_is_initialized == TRUE' failed }}}

Thats interesting because when I do
sudo launchctl list | grep dbus
I do NOT see any output (no org.macports.dbus is running under root)
And my gnu cash starts up with only the messages:

gnc.bin-Message: main: binreloc relocation support was disabled at configure time.

Found Finance::Quote version 1.13

[jonas@…]

Replying to kadorken@…:

I have gnucash 2.2.8 running now under quartz; it starts fine after restarting macos with no special handling.

I've got it running too (using Leopard). In fact, you don't even have to restart if you do a launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist after the installation of dbus. If you're running into troubles with Tiger, just look at the syslog (via Console.app). May you can find something there. Maybe #comment:61 it helpful too.

[jonas@…]

Replying to vinc17@…:

Liferea does: {{{ if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then eval dbus-launch export DBUS_SESSION_BUS_ADDRESS fi }}}

That's a liferea bug. This code is not portable at all (works only on X11 systems) and in addition it's not the business of the client app to start the bus. This is all handled by the dbus lib (on X11 system the lib does the same thing as liferea). As a workaround you could apply a patch dropping this via the Portfile.

If this is a problem, dbus-launch should be symlinked to /usr/bin/true. And how can Liferea get the bus address?

I'd say we should remove dbus-launch, or just make it load the .plist into launchd. It's true that it's currently only a confusing left over.

[olaf@…]

Replying to kadorken@…:

Thats interesting because when I do
sudo launchctl list | grep dbus
I do NOT see any output (no org.macports.dbus is running under root)
And my gnu cash starts up with only the messages: {{{ gnc.bin-Message: main: binreloc relocation support was disabled at configure time. Found Finance::Quote version 1.13 }}}

Yes, that's the expected behaviour. I should mention that I'm on Tiger. I've tried it again. I've even installed the patch from  #comment:61 but with no success. I assume that you and jonas are on Leopard. Is there anyone with a running gnucash/quartz on Tiger?

[jrlaim@…]

Cc Me!

[danstadler@…]

Cc Me!

[jonas@…]

Finally, I set up a G4 with Tiger and tested dbus/gconf/gnucash with +no_x11, -x11 +quartz. It works flawless without any errors. Even the patch from #comment:61 is not necessary as the crash occurs only when using dbus-launch (which is now obsolete, see #comment:18).

Maybe you've got an old fink installation around which adds a startup item for it's own dbus which sets the env var DBUS_SESSION_BUS_ADDRESS. This points gnucash to the wrong session bus which can't start gconfd.... In this case unset DBUS_SESSION_BUS_ADDRESS and try again (and remove fink's dbus startup item).

[olaf@…]

Replying to jonas@…:

Finally, I set up a G4 with Tiger and tested dbus/gconf/gnucash with +no_x11, -x11 +quartz. It works flawless without any errors.

Thank you for your support. I'm glad that 10.4 gets it.

Unfortunately I'm still lost. I've removed MacPorts completely as it is descibed in the FAQ. I've reinstalled it from scratch with +no_x11, -x11 +quartz. The installation went fine. But gnucash has still the same problems. I'm on 10.4 on Intel not G4. Can this make a difference?

Do I need to load /Library/LaunchDaemons/org.macports.dbus.plist ? After the installation it was disabled in the configuration file. I've enabled it but this didn't solve my problem.

I've tried another user account as well as root but the problem is there as well.

Is there a way to narrow down the problem?

[systim@…]

Replying to olaf@…:

Replying to kadorken@…:

Thats interesting because when I do
sudo launchctl list | grep dbus
I do NOT see any output (no org.macports.dbus is running under root)
And my gnu cash starts up with only the messages: {{{ gnc.bin-Message: main: binreloc relocation support was disabled at configure time. Found Finance::Quote version 1.13 }}}

Yes, that's the expected behaviour. I should mention that I'm on Tiger. I've tried it again. I've even installed the patch from  #comment:61 but with no success. I assume that you and jonas are on Leopard. Is there anyone with a running gnucash/quartz on Tiger?

Yes, i installed gnucash 4 days ago from a fresh port installation, i manually startet "d-bus" (launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist) and now i have a running gnucash/quartz on tiger

[macsforever2000@…]

Cc Me!

[olaf@…]

Replying to systim@…:

Yes, i installed gnucash 4 days ago from a fresh port installation, i manually startet "d-bus" (launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist) and now i have a running gnucash/quartz on tiger

Just to make sure: You've succeeded on an Intel machine, haven't you? I've the same yesterday with no success on my Intel Mac mini 10.4.11. Now I'M back to the X11 version but I will try any possible hint.

[insane.dreamer@…]

Replying to systim@…:

Replying to olaf@…:

Replying to kadorken@…:

Thats interesting because when I do
sudo launchctl list | grep dbus
I do NOT see any output (no org.macports.dbus is running under root)
And my gnu cash starts up with only the messages: {{{ gnc.bin-Message: main: binreloc relocation support was disabled at configure time. Found Finance::Quote version 1.13 }}}

Yes, that's the expected behaviour. I should mention that I'm on Tiger. I've tried it again. I've even installed the patch from  #comment:61 but with no success. I assume that you and jonas are on Leopard. Is there anyone with a running gnucash/quartz on Tiger?

Yes, i installed gnucash 4 days ago from a fresh port installation, i manually startet "d-bus" (launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist) and now i have a running gnucash/quartz on tiger

I want to confirm the same positive results. * Added the following variants to /opt/local/etc/macports/variants.conf +no_static +no_x11 -x11 +quartz * Installed gnucash from ports with +without_hbci +no_static +without_quotes. * run: sudo launchctl load -w /Library/LaunchDaemons/org.macports.dbus.plist * run: launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist (no sudo!) * gnucash runs in quartz (be mindful that if you've installed other applications from ports with x11 instead of quartz, you will need to uninstall those and reinstall after adding the above variants to your conf file. See details here:  http://wiki.gnucash.org/wiki/MacOSX/MacPortsDetail#Using_MacPorts_to_install_the_native_Quartz_version_of_GnuCash)

[insane.dreamer@…]

Replying to insane.dreamer@…:

Replying to systim@…:

Replying to olaf@…:

Replying to kadorken@…:

Thats interesting because when I do
sudo launchctl list | grep dbus
I do NOT see any output (no org.macports.dbus is running under root)
And my gnu cash starts up with only the messages: {{{ gnc.bin-Message: main: binreloc relocation support was disabled at configure time. Found Finance::Quote version 1.13 }}}

Yes, that's the expected behaviour. I should mention that I'm on Tiger. I've tried it again. I've even installed the patch from  #comment:61 but with no success. I assume that you and jonas are on Leopard. Is there anyone with a running gnucash/quartz on Tiger?

Yes, i installed gnucash 4 days ago from a fresh port installation, i manually startet "d-bus" (launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist) and now i have a running gnucash/quartz on tiger

I want to confirm the same positive results. * Added the following variants to /opt/local/etc/macports/variants.conf +no_static +no_x11 -x11 +quartz * Installed gnucash from ports with +without_hbci +no_static +without_quotes. * run: sudo launchctl load -w /Library/LaunchDaemons/org.macports.dbus.plist * run: launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist (no sudo!) * gnucash runs in quartz (be mindful that if you've installed other applications from ports with x11 instead of quartz, you will need to uninstall those and reinstall after adding the above variants to your conf file. See details here:  http://wiki.gnucash.org/wiki/MacOSX/MacPortsDetail#Using_MacPorts_to_install_the_native_Quartz_version_of_GnuCash)

PS. I have the following in my .profile 'dbus-launch --auto-syntax'. However, it returns the following error: "EOF in dbus-launch reading address from bus daemon". Despite that, gnucash launches okay.

[jonas@…]

To make it short:

• don't use dbus-launch. It's deprecated as already pointed out several times in this thread.
• Several people, including me, have reported that gnucash (and every other dbus program) works fine with the launchd-based dbus on Tiger as well as on Leopard, on intel as well as on powerpc.
• The failing qof assertion (#comment:74) seems to be an other problem. I'd suggest to open a new ticket for it.

[systim@…]

Replying to olaf@…:

Replying to systim@…:

Yes, i installed gnucash 4 days ago from a fresh port installation, i manually startet "d-bus" (launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist) and now i have a running gnucash/quartz on tiger

Just to make sure: You've succeeded on an Intel machine, haven't you? I've the same yesterday with no success on my Intel Mac mini 10.4.11. Now I'M back to the X11 version but I will try any possible hint.

No I Installed it on a PowerPC

[olaf@…]

Replying to systim@…:

Replying to olaf@…:

Replying to systim@…:

Yes, i installed gnucash 4 days ago from a fresh port installation, i manually startet "d-bus" (launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist) and now i have a running gnucash/quartz on tiger

Just to make sure: You've succeeded on an Intel machine, haven't you? I've the same yesterday with no success on my Intel Mac mini 10.4.11. Now I'M back to the X11 version but I will try any possible hint.

No I Installed it on a PowerPC

So I see no confirmation that my problem has been solved. I've tried it several times but it didn't work. I'd even offer an account on my machine to test the problem.

[jonas@…]

Replying to vinc17@…:

Replying to jonas@…:

Don't use dbus-launch! It has become obsolete since launchd is now responsible of launching the bus.

Liferea does: {{{ if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then eval dbus-launch export DBUS_SESSION_BUS_ADDRESS fi }}}

I think I've got a workaround for apps wich stubbornly require DBUS_SESSION_BUS_ADDRESS to be there instead of trusting the dbus implementation. Just export it to "launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET", the default on launchd enabled systems. So, a line like the following in your .profile should do fine:

export DBUS_SESSION_BUS_ADDRESS="launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET"

[vinc17@…]

Replying to jonas@…:

I think I've got a workaround for apps wich stubbornly require DBUS_SESSION_BUS_ADDRESS to be there instead of trusting the dbus implementation. Just export it to "launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET", the default on launchd enabled systems.

I confirm that this solves the problem.

[anonymous]

Milestone Port Bugs deleted