[Klug-general] DBus Problem

[Peter Childs]

On 10/07/06, Karl Lattimer <karl at nncc.info> wrote:
>
>  > DBus from what I've managed to find out sounds far to complicated and
>  > under documentated to do its job properly. Its probably that modern
>  > graphical OS are complicated full stop.
>
>  I'm going to cut this down pretty succinctly, firstly D-BUS is _VERY_ well
> documented with the obvious tutorial;
>  http://dbus.freedesktop.org/doc/dbus-tutorial.html
>  followed by the homepage index of available documentation;
>  http://www.freedesktop.org/wiki/Software/dbus
>

I did read a review on it and it looked fairly useful and I did
speculate on using it for a programming project. So I did a quick web
search found very little and mostly just got my self confused. I'll
have another look.
The problem is that its a system service that need documenting from a
users point of view because a users got to have it running on their
system. If it seams to cause  you machine to freeze it needs some
simple method of switching debug on to find out what bit is causing it
to freeze.

Peter Childs

>  secondly, D-BUS is not supposed to be a userspace tool, it is a daemon
> which is started in two different ways,
>  1, there is the system message bus started generally with the command;
>      dbus-daemon messagebus --system
>  2, there is the session message bus which is started in userspace something
> like this;
>      dbus-launch --exit-with-session gnome-session
>
>  as far as debugging dbus there is generally no need, once started dbus
> checks the supported features provided by anything installed which has an
> appropriate dbus service attached which can be either putting something on
> the bus, or taking something off, or both.
>
>  D-BUS in short is a very simple method of sending signals via a service
> orientated IPC (inter-process communication) which won't fail in the event
> that an application isn't available to take something off, also D-BUS isn't
> locked down to IPC with a single application/service at a time instead its
> more of a broadcast system.
>
>  Its not very complicated at all, most of the documentation is purely
> developer documentation and for good reason, there isn't really an instance
> where the user needs to get involved with D-BUS. Further I'd like to say
> that modern desktop OS's aren't very complicated, especially as we now know
> what is going on under the hood, after years of windows doing its thing and
> everybody complaining about what it was doing whilst not understanding
> why/how, there is now in existence a free and open architecture which
> provides the same kind of functionality albeit in a more secure POSIX
> security model and most importantly because its open you can take it apart
> and learn how it works.
>
>  Anyway, in order to debug your problem I'd say concentrate more on HAL and
> your hardware/BIOS configuration than D-BUS. The comments in
> http://www.verifysoft.net/2001/dmi_scan.c.html (the so
> called dell laptops hall of shame) should shed some light on how bad some
> hardware can be, specifically around line 116.
>
>  Simplify your hardware before you begin to look for what linux is
> complaining about, modify your bios and turn off anything that isn't
> necessary, remove any hardware that can be removed while still providing a
> functional system.
>
>  Then you should begin by starting your system in single mode simply by
> appending single to your kernel boot params;
>
>  i.e. root=/dev/hda2 vga=791 single
>
>  in grub press "a" then just type " single" without quotes.
>
>  Next thing to do would be to step through your boot process, I don't know
> the details of this on ubuntu, but I'd imagine init 2 waiting then init 3,
> etc upto 5 if all is well, if it crashes at runlevel 3 then you'll probably
> find that that is when D-BUS and HAL are started, so start HAL and D-BUS in
> the order they are supposed to start and see what happens. If you start them
> independently you may see some error which is hidden otherwise.
>
>  Next start the system back up this time in the runlevel before the crash,
> by appending for instance " 2" to your boot params rather than " single"
> then you wanna look inside of your init scripts and run the individual
> commands by hand without making them a background process. You should do
> this on separate terminals first starting D-BUS, then HAL by hand.
>
>  See what happens, once you've got some detail, submit it back to the
> canonical guys for review. You'll probably find that a lot of it will
> already be known about and they'll point you to a fix.
>
>  Hope this helps,
>
>  K,
>
>
> _______________________________________________
> Kent mailing list
> Kent at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/kent
>
>