** Description changed: During session startup, the call to whoopsie_identifier_generate will on some devices leave both buffer and error as NULL. In particular, running http://pastebin.ubuntu.com/7268480/ on mako (and presumably on manta) as a *session* upstart job, with the upstart script of http://pastebin.ubuntu.com/7268498/ will get a null, null for the first 10 seconds (approximately) on mako: Rebooting (boot in dmesg -T at Thu Apr 17 14:32:36 2014, first "init:" line at Thu Apr 17 14:32:44 2014), in the upstart logs I get a series of 2014-04-17T14:32:54+0000 (null) :: <nil> (that's also the first such line ,10s after init) until suddenly 2014-04-17T14:32:56+0000 (null) :: <nil> 2014-04-17T14:32:56+0000 81dc12[...]cd58 :: <nil> I don't know what's causing this, as it doesn't make sense from what I can read in the code. -- The whoopsie bug is now in lp:1311571 -- [Impact] ubuntu-push-client gets an empty string for the whoopsie identifier, which is rather not unique (so connections from multiple devices will get disconnected). [Test Case] You need: * a computer capable of running the ubuntu push server. - * at least two devices using the stable image and that can talk to the computer over the network + * a device using the stable image and that can talk to the computer over the network - on a computer reachable from the devices, do: + on the computer, do: mkdir -p test-case-1309237/src/launchpad.net cd !$ bzr branch lp:ubuntu-push cd ubuntu-push make bootstrap sed -i~ -e 's/127.0.0.1//g' sampleconfigs/dev.json make run-server-dev - on the devices, edit /etc/xdg/ubuntu-push-client/config.json (or copy it + on the device, edit /etc/xdg/ubuntu-push-client/config.json (or copy it to ~phablet/.config/ubuntu-push-client/config.json and edit it there) so that "addr" points to the IP address of the computer, and port 9090; something like "addr": "192.168.1.1:9090" (note there is no https:// as the hosts discovery step is being skipped). - Reboot the devices. Tailing ~phablet/.cache/upstart/ubuntu-push- - client.log will show a series of rapid disconnects and reconnects; the - output of the server will show a series of empty "registered" (as - opposed to "registered" followed by a 256-byte hash). + Reboot the device. The output of the server will show an empty + "registered" (as opposed to "registered" followed by a 256-byte hash). [Regression potential] There's a possibility that whoopsie never stops returning a null string, and thus we never progress. Given that for whoopsie to return null seems to imply there is no network device up, that's probably for the best.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1309237 Title: Work around whoopsie returning null string during session start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-push/+bug/1309237/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
