[Bug 1234731] Re: calling 'initctl set-env -g' from within an upstart job is lost

[Steve Langasek]

The actual problem here is not caused by dbus startup issues.
/usr/share/upstart/sessions/dbus.conf calls 'initctl set-env -g
DBUS_SESSION_BUS_ADDRESS' on startup, but even after login if I call
'initctl list-env -g', this variable is missing.  If I call 'initctl
list-env', it's present - possibly inherited from the dbus job's
environment rather from the global environment, since gnome-session is
'start on started dbus [...]'.

Creating a test job, ~/.config/upstart/env-test.conf, that does the
following:

pre-start script
	initctl set-env --global FOO=bar
end script

And starting this job with 'start env-test', the variable then shows up
correctly in 'initctl list-env -g'.

I don't yet know why the variable exported by dbus is missing, but I can
confirm that this is a common problem across all the variables being set
in /usr/share/upstart/sessions/*.conf; GPG_AGENT_INFO,
DBUS_SESSION_BUS_ADDRESS, SSH_AUTH_*, UBUNTU_MENUPROXY are all missing
from the global env.  GTK_MODULES is there, but presumably arrives by
other means.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1234731

Title:
  calling 'initctl set-env -g' from within an upstart job is lost

Status in Unity HUD:
  Invalid
Status in URL Dispatcher:
  Invalid
Status in “dbus” package in Ubuntu:
  Fix Released
Status in “upstart” package in Ubuntu:
  New

Bug description:
  
  This is an attempt to try to bring a bunch of information together that seems all over the place right now.  I'll try to add what we think I know, but let's everyone try to put other information here as we get it.

  It seems that on some situations Upstart jobs are started that don't
  have the DBUS_SESSION_BUS_ADDRESS environment variable set, even
  though they're "start on started dbus" in their Upstart job.  The
  cases I've seen are for HUD and URL Dispatcher though I'm suspicious
  that indicator-datetime is seeing it as well.  The interesting part
  about these jobs is that one is DBus Activation based (HUD) so we know
  that the DBus job has run and DBus is alive and well.

  Kindly, the URL Launch one happened under testing so we have lots of
  logs:

  http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4525/music-app-
  autopilot/

  The error that URL dispatcher is reporting is that its connection was
  refused:

  https://jenkins.qa.ubuntu.com/job/saucy-touch_ro-maguro-smoke-music-
  app-autopilot/101/artifact/clientlogs/url-dispatcher.log/*view*/

  And when we look at its environment it is shockingly blank:

  https://jenkins.qa.ubuntu.com/job/saucy-touch_ro-maguro-smoke-music-
  app-autopilot/101/artifact/clientlogs/_usr_lib_arm-linux-
  gnueabihf_url-dispatcher_url-dispatcher.32011.crash/*view*/

  The dbus job implies that this can't really happen, but it does...

To manage notifications about this bug go to:
https://bugs.launchpad.net/hud/+bug/1234731/+subscriptions