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

Bug #1234731 reported by Ted Gould
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
URL Dispatcher
Invalid
Undecided
Unassigned
Unity HUD
Invalid
Undecided
Unassigned
dbus (Ubuntu)
New
High
Unassigned
upstart (Ubuntu)
New
Undecided
Unassigned

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...

Ted Gould (ted)
Changed in hud:
status: New → Incomplete
Changed in url-dispatcher:
status: New → Incomplete
Changed in dbus (Ubuntu):
status: New → Confirmed
Revision history for this message
Oliver Grawert (ogra) wrote :
Revision history for this message
Ted Gould (ted) wrote :

Perhaps, but I was unable to figure out who PID 1722 is to blame them :-)

Revision history for this message
Ted Gould (ted) wrote :

Grabbing the environment from the crash file:

$1 = 0xbeed69b1 "PATH=/home/phablet/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
$2 = 0xbeed6a1e "TERM=linux"
$3 = 0xbeed6a29 "USER=phablet"
$4 = 0xbeed6a36 "LANGUAGE=en_US:en"
$5 = 0xbeed6a48 "GRID_UNIT_PX=18"
$6 = 0xbeed6a58 "XDG_SEAT=seat0"
$7 = 0xbeed6a67 "EXTERNAL_STORAGE=/mnt/sdcard"
$8 = 0xbeed6a84 "HOSTNAME=android"
$9 = 0xbeed6a95 "LOOP_MOUNTPOINT=/mnt/obb"
$10 = 0xbeed6aae "SSH_AGENT_PID=1221"
$11 = 0xbeed6ac1 "SHLVL=1"
$12 = 0xbeed6ac9 "HOME=/home/phablet"
$13 = 0xbeed6adc "DESKTOP_SESSION=ubuntu-touch-surfaceflinger"
$14 = 0xbeed6b08 "XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0"
$15 = 0xbeed6b3c "ANDROID_ASSETS=/system/app"
$16 = 0xbeed6b57 "QML2_IMPORT_PATH=/usr/lib/arm-linux-gnueabihf/qt5/imports"
$17 = 0xbeed6b91 "DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-tsYcRUEiJo"
$18 = 0xbeed6bcd "MANDATORY_PATH=/usr/share/gconf/ubuntu-touch-surfaceflinger.mandatory.path"
$19 = 0xbeed6c18 "LOGNAME=phablet"
$20 = 0xbeed6c28 "QT_SELECT=qt5"
$21 = 0xbeed6c36 "DEFAULTS_PATH=/usr/share/gconf/ubuntu-touch-surfaceflinger.default.path"
$22 = 0xbeed6c7e "QTWEBKIT_DPR=2.0"
$23 = 0xbeed6c8f "XDG_SESSION_ID=c1"
$24 = 0xbeed6ca1 "MKSH=/system/bin/sh"
$25 = 0xbeed6cb5 "ANDROID_DATA=/data"
$26 = 0xbeed6cc8 "GDM_LANG=en_US"
$27 = 0xbeed6cd7 "XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0"
$28 = 0xbeed6d11 "XDG_RUNTIME_DIR=/run/user/32011"
$29 = 0xbeed6d31 "ANDROID_ROOT=/system"
$30 = 0xbeed6d46 "XDG_CURRENT_DESKTOP=Unity"
$31 = 0xbeed6d60 "LANG=en_US.UTF-8"
$32 = 0xbeed6d71 "SSH_AUTH_SOCK=/tmp/ssh-gL0Leo99g5Dl/agent.1246"
$33 = 0xbeed6da0 "SHELL=/system/bin/sh"
$34 = 0xbeed6db5 "GDMSESSION=ubuntu-touch-surfaceflinger"
$35 = 0xbeed6ddc "UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/32011/1229"
$36 = 0xbeed6e21 "XDG_VTNR=0"
$37 = 0xbeed6e2c "ASEC_MOUNTPOINT=/mnt/asec"
$38 = 0xbeed6e46 "QT_IM_MODULE=maliitphablet"
$39 = 0xbeed6e61 "ANDROID_PROPERTY_WORKSPACE=8,49152"
$40 = 0xbeed6e84 "PWD=/home/phablet"
$41 = 0xbeed6e96 "QT_QPA_PLATFORM=ubuntu"
$42 = 0xbeed6ead "XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu-touch-surfaceflinger:/etc/xdg"
$43 = 0xbeed6eef "XDG_DATA_DIRS=/usr/share/ubuntu-touch-surfaceflinger:/usr/local/share/:/usr/share/"
$44 = 0xbeed6f42 "ANDROID_CACHE=/cache"
$45 = 0xbeed6f57 "ANDROID_BOOTLOGO=1"
$46 = 0xbeed6f6a "JOB=dbus"
$47 = 0xbeed6f73 "INSTANCE="
$48 = 0xbeed6f7d "UPSTART_EVENTS=started"
$49 = 0xbeed6f94 "UPSTART_JOB=url-dispatcher"
$50 = 0xbeed6faf "UPSTART_INSTANCE="
$51 = 0x0

Revision history for this message
Ted Gould (ted) wrote :

Okay, discussion on IRC seems to believe that this is related to dbus' Upstart job believing that DBus is listening before it actually is (my wife says I have this problem as well). To fix that we need to change the session job to expect a fork, and have the daemon fork, as it will listen before forking.

<jodh> tedg: once you can recreate the problem, I wonder if it is worth tweaking the session dbus.conf job to "expect fork" and "--fork" like the system dbus job already does. That may give a "more correct" started event time.
<tedg> jodh, Why would that be more correct?
<xnox> tedg: dbus forks after it starts to listen, thus expect fork with --fork will make sure started is emitted only after dbus is ready.

Changed in hud:
status: Incomplete → Invalid
Changed in dbus (Ubuntu):
assignee: nobody → Dmitrijs Ledkovs (xnox)
Ted Gould (ted)
Changed in url-dispatcher:
status: Incomplete → Invalid
Changed in dbus (Ubuntu):
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dbus - 1.6.12-0ubuntu6

---------------
dbus (1.6.12-0ubuntu6) saucy; urgency=low

  * Specify --fork to dbus-daemon in upstart user-session mode, to get the
    daemon readiness information and emit started dbus, when dbus is
    actually ready to operate. (LP: #1234731)
 -- Dmitrijs Ledkovs <email address hidden> Thu, 03 Oct 2013 17:32:15 +0100

Changed in dbus (Ubuntu):
status: Confirmed → Fix Released
Steve Langasek (vorlon)
summary: - DBus jobs not setting environment variables
+ calling 'initctl set-env -g' from within an upstart job is lost
Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Revision history for this message
Steve Langasek (vorlon) wrote :

Although looking at my existing login session on my laptop let me reproduce this problem right off the bat, I've had difficulty reproducing it again with subsequent login sessions. The problem, once reproduced, is persistent within upstart, but it's not 100% reproducible between sessions. No idea why yet. I've done 10+ guest login sessions, 5+ logins with a second account on my system, and a restart of my regular user's session, and have yet to reproduce the bug again after adding debugging info to the upstart package here.

Changed in dbus (Ubuntu):
assignee: Dmitrijs Ledkovs (xnox) → nobody
status: Fix Released → New
Revision history for this message
James Hunt (jamesodhunt) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.