#17950 closed defect (fixed)
dbus patched with launchd support and version dump
Reported by: | jonas.baehr@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.7.0 |
Keywords: | launchd kde4 x11 | Cc: | jonas.baehr@…, mtalexander (Mike Alexander), meowsqueak@…, tmdias@…, olaf@…, pgijnxn02@…, vinc17@…, clubjuggler@…, tommyd@…, jrlaim@…, danstadler@…, mf2k (Frank Schima), fang@…, PhilHudson (Phil Hudson) |
Port: | dbus |
Description
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
Attachments (2)
Change History (97)
comment:1 Changed 16 years ago by jonas.baehr@…
comment:2 follow-up: 3 Changed 16 years ago by illogic-al@…
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
comment:3 follow-up: 4 Changed 16 years ago by 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.
comment:4 Changed 16 years ago by 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.
comment:5 follow-up: 6 Changed 16 years ago by mf2k (Frank Schima)
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.
comment:6 Changed 16 years ago by 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)
comment:7 Changed 16 years ago by jonas.baehr@…
Maybe you can also find some hints in the system log using Console.app
comment:8 Changed 16 years ago by mf2k (Frank Schima)
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.
comment:9 follow-up: 10 Changed 16 years ago by 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
comment:10 Changed 16 years ago by mf2k (Frank Schima)
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
comment:11 follow-up: 13 Changed 16 years ago by 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...
comment:12 Changed 16 years ago by mf2k (Frank Schima)
I'm not actually a gnucash user, so i may not get around to reporting it.
comment:13 follow-up: 19 Changed 16 years ago by mtalexander (Mike Alexander)
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?
comment:15 follow-ups: 17 18 Changed 16 years ago by tcwan (TC Wan)
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
comment:17 Changed 16 years ago by 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?
comment:18 follow-up: 25 Changed 16 years ago by 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)
comment:19 Changed 16 years ago by 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).
comment:20 follow-up: 24 Changed 16 years ago by mtalexander (Mike Alexander)
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.
comment:21 Changed 16 years ago by mf2k (Frank Schima)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I'm re-opening this for now.
comment:22 Changed 16 years ago by mf2k (Frank Schima)
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.
comment:24 Changed 16 years ago by 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!
comment:25 Changed 16 years ago by 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).
comment:27 follow-ups: 28 30 31 33 Changed 16 years ago by 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.
comment:28 follow-up: 29 Changed 16 years ago by 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.
comment:29 Changed 16 years ago by mf2k (Frank Schima)
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.
comment:30 Changed 16 years ago by 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.
comment:31 Changed 16 years ago by tcwan (TC Wan)
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 launchinggconf-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).
comment:33 follow-up: 34 Changed 16 years ago by mtalexander (Mike Alexander)
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 launchinggconf-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.
comment:34 follow-up: 35 Changed 16 years ago by 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 launchinggconf-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.
comment:35 follow-up: 36 Changed 16 years ago by mtalexander (Mike Alexander)
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.
comment:36 follow-up: 37 Changed 16 years ago by 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!
comment:37 follow-up: 39 Changed 16 years ago by mtalexander (Mike Alexander)
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.
comment:39 follow-up: 41 Changed 16 years ago by 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.
comment:41 Changed 16 years ago by mtalexander (Mike Alexander)
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.
comment:42 follow-up: 44 Changed 16 years ago by 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...
comment:44 follow-up: 45 Changed 16 years ago by mtalexander (Mike Alexander)
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.
Changed 16 years ago by mtalexander (Mike Alexander)
Attachment: | patch-launchd-part2.diff added |
---|
Patch for changes to launchd support.
comment:45 Changed 16 years ago by 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?
Changed 16 years ago by jonas.baehr@…
Attachment: | dbus-1.2.12-port-with-lunchd-patch.tar.bz2 added |
---|
New version of the dbus patch, now everything should work
comment:46 follow-ups: 49 50 Changed 16 years ago by 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.
comment:47 follow-ups: 48 51 Changed 16 years ago by mf2k (Frank Schima)
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?
comment:48 Changed 16 years ago by 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.
comment:49 follow-up: 52 Changed 16 years ago by mtalexander (Mike Alexander)
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.
comment:50 Changed 16 years ago by mtalexander (Mike Alexander)
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.
comment:51 Changed 16 years ago by 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.
comment:52 follow-up: 54 Changed 16 years ago by 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.
comment:53 follow-ups: 55 56 Changed 16 years ago by mf2k (Frank Schima)
Committed revision r45725. This version finally works for me. Thanks! Let's wait for some feedback before closing this ticket though.
comment:54 Changed 16 years ago by mtalexander (Mike Alexander)
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.
comment:55 Changed 16 years ago by 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!
comment:56 follow-up: 59 Changed 16 years ago by 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]
comment:57 follow-up: 58 Changed 16 years ago by vinc17@…
Milestone: | Port Enhancements → Port Bugs |
---|---|
Type: | enhancement → defect |
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.
comment:58 follow-up: 60 Changed 16 years ago by 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)
comment:59 follow-up: 62 Changed 16 years ago by 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
comment:60 follow-up: 61 Changed 16 years ago by mtalexander (Mike Alexander)
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.
comment:61 follow-up: 64 Changed 16 years ago by 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.
comment:62 follow-up: 63 Changed 16 years ago by 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?
comment:63 Changed 16 years ago by 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.plistAfter 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.
comment:64 Changed 16 years ago by 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?
comment:65 follow-up: 66 Changed 16 years ago by tcwan (TC Wan)
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).
comment:66 follow-up: 67 Changed 16 years ago by 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
comment:67 Changed 16 years ago by 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
comment:68 follow-ups: 69 71 73 Changed 16 years ago by 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)
comment:69 follow-up: 70 Changed 16 years ago by 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.
comment:70 Changed 16 years ago by 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
comment:71 follow-up: 72 Changed 16 years ago by 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?
comment:72 follow-ups: 74 76 Changed 16 years ago by 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)
comment:73 follow-ups: 77 91 Changed 16 years ago by 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?
comment:74 follow-up: 75 Changed 16 years ago by 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.
comment:75 follow-up: 78 Changed 16 years ago by 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
comment:76 Changed 16 years ago by 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.
comment:77 Changed 16 years ago by 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.
comment:78 follow-up: 83 Changed 16 years ago by 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?
comment:81 follow-up: 82 Changed 16 years ago by 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).
comment:82 Changed 16 years ago by 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?
comment:83 follow-ups: 85 86 Changed 16 years ago by 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.13Yes, 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
comment:85 follow-up: 89 Changed 16 years ago by 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.
comment:86 follow-up: 87 Changed 16 years ago by 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.13Yes, 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)
comment:87 Changed 16 years ago by 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.13Yes, 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.
comment:88 Changed 16 years ago by jonas@…
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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.
comment:89 follow-up: 90 Changed 16 years ago by 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
comment:90 Changed 16 years ago by 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.
comment:91 follow-up: 92 Changed 16 years ago by 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"
comment:92 Changed 16 years ago by 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.
With this port, dbus-legacy, see r44934, is no more necessary.