meego-ux-daemon started with bad dbus environment in SDK? [Was: MNotification on MeeGo Tablet UX]

[Andy Ross]

[Starting a new thread as this is no longer a MNotification issue]

/etc/xdg/autostart/meego-ux-daemon.desktop is there, and indeed
meego-ux-daemon is started after I do `startmeego`.

And yet you need another copy started despite having one already
running? Yeah, I think Rusty is right; somehow it's on the wrong bus.

This is definitely looking like an SDK initialization issue. Can some
of the SDK people please chime in here? I honestly don't use it, so
I'm a little lost trying to debug it via email.

To start the ball rolling, can you grab the output of "qdbus" in both
your host and SDK environments right after a clean SDK startup? If
you see meego-ux-daemon running, grab its process ID and the contents
of /proc/<pid>/environ as well as the output of "env" in a shell in
both the host and the SDK. That should be enough to prove/disprove
the "wrong bus" hypothesis.

I wonder if that can have anything to do with mic-chroot bind mounting
the following?
/var/run/dbus -> /chroots/meego/var/run/dbus
/var/lib/dbus -> /chroots/meego/var/lib/dbus

It seems unlikley, those are for the system bus (i.e. the SDK shares
the system bus of the host? That strikes me as likely to cause
trouble too, but maybe it's unavoidable?). MNotification is a service
on the session bus, which is managed out of the user home driectory

Andy

[Salvatore Iovene]

Hi,

On Mon, 13 Jun 2011 08:35:49 -0700

Post by Andy Ross
[Starting a new thread as this is no longer a MNotification issue]

/etc/xdg/autostart/meego-ux-daemon.desktop is there, and indeed
meego-ux-daemon is started after I do `startmeego`.

And yet you need another copy started despite having one already
running? Yeah, I think Rusty is right; somehow it's on the wrong bus.
This is definitely looking like an SDK initialization issue. Can some
of the SDK people please chime in here? I honestly don't use it, so
I'm a little lost trying to debug it via email.
To start the ball rolling, can you grab the output of "qdbus" in both
your host and SDK environments right after a clean SDK startup? If
you see meego-ux-daemon running, grab its process ID and the contents
of /proc/<pid>/environ as well as the output of "env" in a shell in
both the host and the SDK. That should be enough to prove/disprove
the "wrong bus" hypothesis.

Everything you asked is attached. Still it looks like the buses are
different, at least judging from the DBUS_SESSION_BUS_ADDRESS
in /proc/<pid>/environ.

Thanks for looking!

[Thiago Macieira]

Post by Salvatore Iovene

Post by Andy Ross
To start the ball rolling, can you grab the output of "qdbus" in both
your host and SDK environments right after a clean SDK startup? If
you see meego-ux-daemon running, grab its process ID and the contents
of /proc/<pid>/environ as well as the output of "env" in a shell in
both the host and the SDK. That should be enough to prove/disprove
the "wrong bus" hypothesis.

Everything you asked is attached. Still it looks like the buses are
different, at least judging from the DBUS_SESSION_BUS_ADDRESS
in /proc/<pid>/environ.

Well, it proves the wrong bus hypothesis.

In the second environment, no DBUS_SESSION_BUS_ADDRESS is set, so a new bus is
automatically started if a previous one isn't found. The previous one is found
if you're running with the same:

1) user ID
2) X display
3) machine (machine ID file: /var/lib/dbus/machine-id)

Can you check which one isn't matching?

[Feng, Haitao]

Hi,

We use startmeego to start up a new session bus. This session bus ID
could be retrieved by starting the MeeGo terminal application in the
MeeGo UX panel and type
echo $DBUS_SESSION_BUS_ADDRESS

You could use this session bus as well when you start your application
in the MeeGo terminal.

Thanks
-Haitao

Post by Thiago Macieira

Post by Salvatore Iovene

Post by Andy Ross
To start the ball rolling, can you grab the output of "qdbus" in both
your host and SDK environments right after a clean SDK startup? If
you see meego-ux-daemon running, grab its process ID and the contents
of /proc/<pid>/environ as well as the output of "env" in a shell in
both the host and the SDK. That should be enough to prove/disprove
the "wrong bus" hypothesis.

Everything you asked is attached. Still it looks like the buses are
different, at least judging from the DBUS_SESSION_BUS_ADDRESS
in /proc/<pid>/environ.

Well, it proves the wrong bus hypothesis.
In the second environment, no DBUS_SESSION_BUS_ADDRESS is set, so a new bus is
automatically started if a previous one isn't found. The previous one is found
1) user ID
2) X display
3) machine (machine ID file: /var/lib/dbus/machine-id)
Can you check which one isn't matching?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
_______________________________________________
MeeGo-sdk mailing list
http://lists.meego.com/listinfo/meego-sdk
http://wiki.meego.com/Mailing_list_guidelines
http://meego.com/developers

[Salvatore Iovene]

Hi,

On Tue, 14 Jun 2011 15:25:07 +0800

Post by Feng, Haitao
We use startmeego to start up a new session bus. This session bus ID
could be retrieved by starting the MeeGo terminal application in the
MeeGo UX panel and type
echo $DBUS_SESSION_BUS_ADDRESS
You could use this session bus as well when you start your application
in the MeeGo terminal.

That works. So shouldn't this happen automatically? :)

[Andy Ross]

Post by Feng, Haitao
You could use this session bus as well when you start your application
in the MeeGo terminal.

Yes, but what starts meego-ux-daemon? That code is *not* using the correct
session bus.

Andy

[Salvatore Iovene]

On Tue, 14 Jun 2011 05:59:13 -0700

Post by Andy Ross

Post by Feng, Haitao
You could use this session bus as well when you start your
application in the MeeGo terminal.

Yes, but what starts meego-ux-daemon? That code is *not* using the
correct session bus.

No, I don't think that's the problem. I actually think that
meego-ux-daemon is running on the correct bus, but since
DBUS_SESSION_BUS_ADDRESS was unset in my terminal, dbus-send was not
working, hence the problem.

[Andy Ross]

Post by Salvatore Iovene
No, I don't think that's the problem. I actually think that
meego-ux-daemon is running on the correct bus, but since
DBUS_SESSION_BUS_ADDRESS was unset in my terminal, dbus-send was not
working, hence the problem.

Yeah, I was looking at the wrong files. Up too early with the toddler. :)

Maybe I'm confused -- I thought the SDK had a terminal launcher that automatically
slurped this out of the running desktop environment, no?

If not, you'll need to play one of the tricks to get it. I use this on devices
as a quick one-liner I can append to /home/meego/.bashrc. I'm sure others have
similar:

eval $(tr '\0' '\n' < /proc/`pidof mcompositor`/environ | egrep '^(DISPLAY|X|DBUS|AG_|QMF_)' | sed 's/^/export /')

Andy

[Salvatore Iovene]

On Tue, 14 Jun 2011 06:10:44 -0700

Post by Andy Ross
eval $(tr '\0' '\n' < /proc/`pidof mcompositor`/environ | egrep
'^(DISPLAY|X|DBUS|AG_|QMF_)' | sed 's/^/export /')

Thanks, dutifully noted :)

[Salvatore Iovene]

On Tue, 14 Jun 2011 09:01:17 +0200

Em Tuesday, 14 de June de 2011, às 09:33:16, Salvatore Iovene

Post by Salvatore Iovene

Post by Andy Ross
To start the ball rolling, can you grab the output of "qdbus" in
both your host and SDK environments right after a clean SDK
startup? If you see meego-ux-daemon running, grab its process ID
and the contents of /proc/<pid>/environ as well as the output of
"env" in a shell in both the host and the SDK. That should be
enough to prove/disprove the "wrong bus" hypothesis.

Everything you asked is attached. Still it looks like the buses are
different, at least judging from the DBUS_SESSION_BUS_ADDRESS
in /proc/<pid>/environ.

Well, it proves the wrong bus hypothesis.
In the second environment, no DBUS_SESSION_BUS_ADDRESS is set, so a
new bus is automatically started if a previous one isn't found.

When you say "the second environment", you mean the chrooted meego
environment, that I labeled with the -sdk prefix in the files I
attached?

Or are we talking of before/after starmeego is run, but always within
the chrooted meego environment?

1) user ID
2) X display
3) machine (machine ID file: /var/lib/dbus/machine-id)
Can you check which one isn't matching?

If you're talking about comparing those things between the host OS and
the chrooted meego environment, then possibly the user ID doesn't match.

Within the chrooted meego environment, I'm running things as root; but
on the host OS, the DBUS_SESSION_BUS_ADDRESS is not present in root's
`env`.

Also, the output of `ps aux | grep dbus` tells that:

1) `dbus-daemon --system --fork --activation=upstart` is
running with UID 112 (user "saned")
2) `/bin/dbus-daemon --fork --print-pid 5 --print-address 7
--session`is running as root, twice (2 pids)
3) A few instances of `dbus-launch` are running both as root and as
"siovene" (my local username)

I hope this help.
Thanks!

[Patrick Ohly]

Post by Andy Ross
[Starting a new thread as this is no longer a MNotification issue]

/etc/xdg/autostart/meego-ux-daemon.desktop is there, and indeed
meego-ux-daemon is started after I do `startmeego`.

And yet you need another copy started despite having one already
running? Yeah, I think Rusty is right; somehow it's on the wrong bus.
This is definitely looking like an SDK initialization issue. Can some
of the SDK people please chime in here? I honestly don't use it, so
I'm a little lost trying to debug it via email.

When using the chroot method and starting the UX via
"startmeego[-tablet]", a D-Bus session is started. Inheriting that
environment in a shell is a bit involved. One of the following methods
work:
* run xterm inside UX, run commands there
* run xterm inside UX, run screen, detach, reattach elsewhere
* change startmeego script

I personally use the last approach. I run mcompositor in the background,
then invoke a bash:

# Start panels in advance
mcompositor &

# start shell instead
bash </dev/tty

With this change, I get an interactive shell with the same environment
as the rest of the UX.

The /dev/tty redirect might be an artifact from my earlier experiments
with redirecting stdin for commands; it might no longer be necessary.