Re: [zones-discuss] dbus in local zones
Glenn Faden wrote: I understood that. What I didn't understand was why there wasn't a completely separate instance of the dbus-daemon running in each zone, with its own rendezvous file for communicating with clients in that zone. Why would you expect there to be cross-zone communication here? Some kind of zone-awareness needs to be integrated into HAL and/or dbus to deliver notification events (like hot plugging) to appropriate consumers. I don't have a proposal at this point. Hmm. I didn't read enough of the D-Bus materials to see the kernel interaction; I only read the part about inter-process communications. Still, it seems like the two should be mostly separable, that the IPC aspects should be straightforward to support in local zones. Kernel communications might not be available without zone support, but presumably there is a significant class of applications that would still be interesting - notably probably including the text editor that was the start of the conversation. (Disclaimer: I'm speaking entirely from a 100K-foot view, with almost no knowledge of how D-bus is implemented or used.) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
dbus-daemon cannot be run in non-global zones Sure sounds like the question is why not?. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
I thought I answered that. The dbus-daemon is using a UNIX domain rendezvous file in /tmp in the global zone. The non-global zones have their own instances of /tmp, so the rendezvous file does not exist in their namespace. Even if it did, there would be other problems because the devices that get reported to HAL by the dbus-daemon don't exist in the non-global zones. HAL isn't zone-aware. --Glenn Jordan Brown (Sun) wrote: dbus-daemon cannot be run in non-global zones Sure sounds like the question is why not?. ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
Glenn Faden wrote: I thought I answered that. The dbus-daemon is using a UNIX domain rendezvous file in /tmp in the global zone. The non-global zones have their own instances of /tmp, so the rendezvous file does not exist in their namespace. Even if it did, there would be other problems because the devices that get reported to HAL by the dbus-daemon don't exist in the non-global zones. HAL isn't zone-aware. I understood that. What I didn't understand was why there wasn't a completely separate instance of the dbus-daemon running in each zone, with its own rendezvous file for communicating with clients in that zone. Why would you expect there to be cross-zone communication here? ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] dbus in local zones
Hi I succesfully compiled the editor SciTE for Solaris and it works without problems in the Global Zone. But in a non-global zone it does not fully work: I can start the editor with a file and edit that file but trying to open a file from within the editor crashes the editor: [Sun Jan 13 21:36:05 [EMAIL PROTECTED] /var/develop/scite/scite/gtk] # ../bin/SciTE process 25006: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open /var/lib/dbus/machine-id: No such file or directory See the manual page for dbus-uuidgen to correct this issue. D-Bus not built with -rdynamic so unable to print a backtrace Abort (core dumped) [Sun Jan 13 21:37:13 [EMAIL PROTECTED] /var/develop/scite/scite/gtk] # ls /var/lib/dbus/machine-id /var/lib/dbus/machine-id: No such file or directory When I look at the dbus service in the zone I see that it is disabled [Sun Jan 13 21:37:35 [EMAIL PROTECTED] /var/develop/scite/scite/gtk] # svcs -a | grep dbus disabled 18:38:52 svc:/system/dbus:default and according to the log file of the service it cannot be run in a non-global zone: dbus-daemon cannot be run in non-global zones Because I don't know exactly for what the dbus daemon is used I would like to know, if I can work around this error from Solaris (e.g. by creating the missing file manually) or do I have to check the application to not use the dbus at all? (My test environment is Solaris snv_78 for SPARC) regards Bernd -- Bernd Schemmer, Frankfurt am Main, Germany http://home.arcor.de/bnsmb/index.html M s temprano que tarde el mundo cambiar . Fidel Castro ___ zones-discuss mailing list zones-discuss@opensolaris.org
