=== asac` is now known as asac === tgm4883_ is now known as tgm4883 [04:36] Good morning [05:07] ScottK, ping [05:09] ScottK, for the effects/compositing setup: should be what comes as default when installing kubuntu-desktop [05:14] tvoss_: OK. Thanks. In the video, the effects looked less transparent, but that may just be the video. It would have been nice to see more actual compositing effects demonstrated and some KDE apps. [05:15] I don't feel like I got much of a feel for it as it was. [05:20] ScottK, hmmm, I can try with vanilla X and see if I notice any changes [05:20] ScottK, any particular operation you want me to check except for playing around with it a little longer? [05:24] I'd be interested to see various window switching effects, like present windows, , box switch, cover switch, as well as some of the other effects like the outline effect on a focused window and the dialog darken effect. [05:24] I think seeing things like that are directly driven by kwin when using KDE apps would be more representative. [05:27] superm1: Would you please update the mythbuntu metapackage/seeds: http://people.canonical.com/~ubuntu-archive/NBS/ttf-droid [05:34] ScottK, happy to do that, a screen cap is fine with you? [05:35] tvoss_: Sure. Just trying to get a better idea of it. === ballock is now known as tokarbol [05:45] ScottK, mind pointing me at the keyboard shortcuts to activate the effects you want to see? [05:46] For present windows, I normally move my cursor to the upper left corner. [05:46] The window switching ones are alt-tab [05:47] I think ctrl f10 for present windows [05:47] ScottK, cool, thx :) [05:47] the outline effect should be visible if you have multiple overlapping apps in the screen and one has focus. [05:48] For the darken dialog one, you'll have to arrange to have something pop up a diaglog [05:48] ScottK, ack, any specific kde app you want to see? === jono is now known as Guest59629 [05:49] No, it's more about the windeco/window than the contents. [05:49] Trying to exercise the things that kwin has direct control over. [05:51] ScottK, sure [06:00] * tvoss_ is off to kubuntu land for a minute or two :) [07:06] ScottK, uploading to u1 [07:06] Does that result in it going somewhere I can see it? [07:07] ScottK, hmmm, I assumed you would have a u1 account [07:07] ScottK, if not, where do you want me to put it? [07:07] Nope. [07:07] Anywhere public is fine. [07:07] ScottK, let me see, youtube should work [07:07] I don't believe in storing data on systems I don't control. [07:07] Yeah. [07:08] At least not anything that shouldn't be public. [07:08] ScottK, fair [07:11] ScottK, I noticed that tracker is using quite a lot of cpu in the background. do you kick it off by default on session login? === smb` is now known as smb [07:23] ScottK, hth: https://www.youtube.com/watch?v=8sKQnDAPEA4 [07:31] I don't think nepomuk uses that normally, but that's probably what it is. It can bog things down a bit on first run. [07:32] tvoss: Looks pretty good. I get a much better sense of it from that. [07:33] ScottK, cool, glad that I could help [07:33] You might want to mention that in the comments to the first one or something. [07:33] ScottK, I will drop a mail to Jono [07:48] good morning [07:48] dholbach, good morning my german friend! wie gehts? [07:50] hey seb128 - good good - yourself? [07:50] dholbach, I'm good thanks ;-) === doko_ is now known as doko [09:55] why is openssh-server not in saucy? [09:56] brendand: err, it better was.. and it is [09:56] openssh-server | 1:6.2p2-5 | saucy | amd64, armhf, i386, powerpc [09:56] pitti, apt-cache search doesn't find it [09:57] neither devscripts! [09:57] something is wrong with my install then (most recent daily image) [09:58] brendand: did you run apt-get update to get the package lists?! [09:58] nothing wrong with sources.list [09:58] ah, snap. [09:58] xnox, doing that now [09:59] xnox, that's a bug then, no? [10:01] brendand: apt-cache is fully offline, it only looks up things in the downloaded package files. [10:02] xnox, ah i know now - i couldn't get a connection during install because of a bug in ubiquity [10:03] xnox, ergo it didn't run apt-get update during install (succesfully anyway) [10:03] brendand: hence..... no caches. I do think that ubiquity in those cases should copy the stale cache from the cd though. [10:03] but not sure if this should be implemented or not. [10:03] is there one ? [10:03] ogra_: let me check. [10:03] i thought the cache is wiped during build [10:04] to save space [10:05] ogra_: in /var/cache/apt/ pkgcache.bin is 5.1M and srcpkgcache.bin is 5.0M and nothing under archives/ [10:05] is that installed packages though?! [10:06] ogra_: all is there for main and restricted under /var/lib/apt/lists/ 12M [10:06] hmm, could be a full cache should be bigger [10:07] we wipe /var/lib/apt/lists/ though [10:07] not sure the cache helps much without the list files [10:08] but lists files are there as well. [10:08] oh ? [10:08] inside the squashfs ? [10:08] yeap. [10:08] i always thought apt-setup handles them [10:08] from casper [10:09] ogra_: http://paste.ubuntu.com/5807347/ [10:09] yeah, i see [10:12] jodh, hey ho [10:16] So cgroups' kernel interface is changing, and non-systemd systems will need new code to cope: https://lwn.net/Articles/555920/ [10:17] How much does this affect Ubuntu? Do we now need to write a cgroup manager? [10:18] hallyn: ^^ will this affect LXC at all? [10:18] rbasak: I don't think it affects upstart a lot, but ICBW; it will affect containers (but that's being discussed upstream) and logind (but that will be handled by upstream, too) [10:18] pitti: rbasak: It would be interesting to know if/how it affects lxc on ubuntu and nested-lxc on ubuntu. [10:19] I asked stgraber about this the other day [10:19] definitely [10:19] given an essential bit of our stuff today depends on lxc [10:19] (touch, cloud) [10:20] How much do we need cgroup support in LXC? [10:20] .... all of it? [10:21] yeah [10:21] without it it is just a chroot :) [10:22] rbasak: for us this mostly amounts to pay attention to shipping matching kernel and lxc versions, AFAICS [10:22] Without cgroups there's still namespacing and apparmor [10:23] I guess on phone it'll be bad if an app uses 100% CPU or something [10:23] on the phone you will get issues with the running android init [10:23] Thanks for the comments anyway. I just saw the article and thought we might want to pay attention. I guess hallyn is the expert here for the LXC end of things [10:40] ogra_: hi [10:41] jodh, so we have some slight probs with the container handling on ubuntu touch ... and i was wondering if upstart could help us ... [10:41] effectively we do not want the ubuntu system to handle certain things while android does the same inside the container [10:41] i.e. see bug 1190792 [10:41] bug 1190792 in touch-preview-images "ueventd in a busy loop on container-flipped image" [High,Confirmed] https://launchpad.net/bugs/1190792 [10:41] (we have plenty of such stuff) [10:42] jodh, i was wondering if it would be possible to have something like an init-to-init-bridge between the two so we can see in upstart what happens inside the container to then adjust our event handling accordingly [10:44] ogra_: so you're talking about having androids init in lxc emitting events to the host systems upstart? [10:44] right [10:44] some kind of communication layer between host and container [10:46] currently we have a lot of override jobs that i.e. look for the existence of a socket and then fire the ubuntu process ... thats horridly racy [10:48] also bringing up the container on boot indeed costs several seconds, atm we can just wait for lxc-wait to make sure the OS inside the container is up, but that doesnt tell us if there is still stuff being processed ... racy again ... [10:49] if we could instead have a listener for the specific in-conrainer job to start when the services inside the container runs we wouldnt have to wait for the whole container to be up and could start bits in parallel [10:55] ogra_: I guess the hacky way might be to poll with tools like lxc-ls/lxc-ps/lxc-nestat, but awe mentioned that some android services aren't even ready when the sockets appear so maybe we'd need to consider some sort of android service that talks back to the host? don't know enough about this tbh. [10:56] well, thats what i'm proposing :) [10:57] have either a hook in androids init (if it knows enough to give us any info) or have a watcher process that tells upstart about started processes [10:57] and yeah, apps can indeed create sockets before they are ready and fully attached, thats one of the probs we have [11:00] what we currently plan (and wich is really ugly) is for i.e. ueventd have it create a file in a shared space once it is done (kind of a udevadm settle with files) and have udev have a file-bridge handler watching it [11:01] i'm not proposing this for 13.10 but i think we should plan something similar for 14.04 [11:01] (unless you think it's super easy and a thing of a days work to implement :) ) [11:06] jamespage, could you have a look at all the maven build failures in the test rebuild? [11:07] ogra_: you could do that now: [11:07] ogra_: 'start on file FILE=/var/lib/lxc/raring/rootfs/tmp/foo EVENT=created' [11:08] not really, /var/lib/lxc/raring/rootfs/tmp/foo would never show up [11:08] ogra_: ? [11:09] /var/lib/lxc/raring/rootfs is only the input your container runs somewhere in /proc [11:09] so files created in /tmp would show up in /proc/$lxc-pid/root/tmp ... [11:10] but we dont have $lxc-pid unless we explicitly process lxc-info output [11:13] ogra_: a watcher process sounds like it would get more traction that hacking androids init, but I don't know what env is available to allow it to talk back to the host. maybe those that know lxc+android better than I could comment on a bp if you raise one? [11:13] you can create a socket in /dev/socket, thats shared for example [11:14] and /data will always be a shared dir since binary blobs depend on it on both sides [11:15] but while we will likely use the file approach through /data i dont think thats a proper solution [11:15] (in the long term) === MacSlow is now known as MacSlow|lunch [11:47] jodh, oh, btw, i had tried to watch a socket with the file bridge ... seems i cant, it only seems to act on regular files, do you consider that a bug ? [12:35] rbasak: pitti: the actual kernel cgroups changes are somewhat independent of the systemd announcement [12:36] at some point it'll require a single unified hierarchy - that's no problem for us [12:36] lemme find the most soothing email in the thread, [12:37] http://lkml.org/lkml/2013/6/27/527 [12:37] rbasak: ^ tl;dr : we'll all be experimenting for awhile and coming up wtih a new api [12:37] ogra_: the bridge is using inotify, so I guess it's a limitation of inotify. [12:37] ah [12:37] the api is to set on *top* of cgroupfs, and we do want such a thing. But if we want to be phillistines, we can always keep using cgroupfs :) === wedgwood_away is now known as wedgwood === MacSlow|lunch is now known as MacSlow [13:19] didrocks, what is the blessed way to install a symlink from a packaging setup? [13:19] tvoss_: just do it like in a file, ship it, then dh_links will do the right thing for you :) [13:19] dh_link* === _salem is now known as salem_ [13:20] tvoss_: you can force creating some shipping debian/.links (man dh_link) [13:20] didrocks, thx [13:20] yw :) [13:53] xnox: hi! about bug 1194195, the binary package depending on gksu was checkbox-gtk, so all should be peachy if I remove that particular dep, right? (I'll be adding a depends on policykit-1 instead, in addition to code changes) [13:54] bug 1097816 in checkbox (Ubuntu) "duplicate for #1194195 Checkbox needs to use pkexec instead of gksu" [High,In progress] https://launchpad.net/bugs/1097816 === kentb-out is now known as kentb [14:19] roadmr: yes. [14:19] xnox: ok, great! thanks. A fix should land in a few days then :) [14:20] roadmr: awesome. [14:22] mdeslaur: I've created a apparmor-easyprof-ubuntu package to ship our templates and policygroups [14:22] mterry: To be clear on bug #1188935, were you okay with that being promoted despite the testsuite bug, or did you want that fixed first? [14:22] bug 1188935 in python-secretstorage (Ubuntu) "[MIR] python-secretstorage" [Undecided,Fix committed] https://launchpad.net/bugs/1188935 [14:22] jdstrand: ok [14:22] mdeslaur: the current version is 'ubuntu-0'. ie, things are installed in: [14:22] /usr/share/apparmor/easyprof/templates/ubuntu-0/ubuntu-sdk [14:22] /usr/share/apparmor/easyprof/policygroups/ubuntu-0/qmlscene [14:22] infinity, I'm OK despite the test suite bug. I just want the test suite bug fixed this cycle ideally [14:23] jdstrand: version 0? :P [14:23] jdstrand: odd choice :P [14:23] mterry: Check. Promoting, then. [14:23] Or whenever gnome-keyring can be run under xvfb [14:23] mdeslaur: I used 'ubuntu-0' just for namespacing. ie, the json manifest would use '"policy_version": "ubuntu-0"' [14:23] oh, yuck [14:24] why not just an integer there? [14:24] compating strings is painful [14:24] comparing [14:24] easyprof supports that fine, I chose ubuntu-0 for namespacing [14:26] *cough*ugly*cough* [14:26] mdeslaur: eg, if Debian wanted to ship easyprof templates, we would need to not collide [14:26] ok, if you want to do that, then do policy_vendor and policy_version [14:26] jeez, you keep making me do more work :P [14:26] because now we have to start parsing strings all over if we want to do "older than version 3" checks [14:26] jdstrand: well, do it right the first time :) [14:26] meh [14:26] hehe [14:27] * mdeslaur hugs jdstrand [14:37] cjwatson: hey, recalling the question about sdk apps and click, the fat package format is supposed to solve the arch specific packages right? I see there's an architecture entry I could add to the manifest today to workaround that until it's ready if that's the case [14:41] sergiusens: fat packages are only needed if you want to ship multiple arches. if you just need to ship one then you can just say "architecture": "armhf" [14:42] the "problem" of shipping packages for a single architecture isn't one that needs solving :) [14:43] cjwatson: great, so my temporary hack would be to use arch: armhf, but these apps would eventually need to be fattened up [14:44] or linked or something [14:44] we don't need to solve that problem just yet [14:45] one less problem to deal with for now, I'll table it === kentb is now known as kentb-afk [14:55] manish: so this is going to be tricky. Since [14:56] activity log manager by itself is only vala code, not a c shim like the control center integration, it means extern'ing enough c code in alm.vala to get the diagnostics page up [14:56] manish: I'll keep at it, but can we release what we have? As the previous release disabled the diagnostics page, GNOME Ubuntu would be no worse off. [14:59] ev: that release wasn't in Ubuntu because it had a regression like that [14:59] jbicha: what's the regression? [14:59] the diagnostics page never appeared in a-l-m standalone. [15:00] what I meant was that alm 0.9.5 wasn't in Ubuntu [15:00] oh, right [15:02] ev: based on what you've said, I'm ok with releasing to saucy now with bug 1192778 unfixed but I'd really like it fixed before saucy is released [15:02] bug 1192778 in Activity Log Manager "Diagnostics tab doesn't show in standalone mode" [Medium,Confirmed] https://launchpad.net/bugs/1192778 [15:03] jbicha: *nods* I'm working on it, I just don't want the release to block on it. :) [15:13] jbicha: the debdiff in lp: #1194526 comment #4 doesn't apply cleanly to the current saucy branch of libgsf. can you generate a new patch? if not, i will adapt it [15:14] Launchpad bug 1194526 in libgsf (Ubuntu) "Merge libgsf 1.14.27-1 (main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/1194526 [15:20] barry: Meh, I'll just do that merge myself right now, it's trivial. [15:21] infinity: thanks [15:22] thanks [15:28] * infinity resurrects a lost changelog entry while he's at it. [15:33] slangasek, what would be in local-filesystems that is not in filesystems ? [15:33] ie, i have a system hung where local-filesystems ahs fired but not filesystems === kentb-afk is now known as kentb === jtechidna is now known as JontheEchidna [15:54] hm.. [15:57] what is responsible for clearing /forcefsck after it's been done? [15:58] smoser: I guess you mean the other way around? things in filesystem but not in local-filesystems; that would be network filesystems, by and large... 'filesystem' should be the union of 'local-filesystems' and 'remote-filesystems' IIRC [16:01] yeah. [16:01] slangasek, do you have a minute [16:01] smb: we even have a picture: http://upstart.ubuntu.com/cookbook/#mountall-event-summary :) [16:01] smoser: ok [16:02] ssh test@gwaclhostblkhljy4re3yp9swkdwp63kswkss9bqhn0zm3f3gunipzu5vwdr8qzw.cloudapp.net [16:02] that system i think has not run rc yet. and i *thoht* had not emitted filesystme, but i don thtink thats rignht [16:03] smoser: cannot resolve hostname [16:03] smb: oops - should have been smoser ;) [16:03] jodh, Very ..err nice. Why would we want that again. :) [16:03] ah [16:03] slangasek, would it seem odd or bad for [16:03] lockfile-create /var/lock/ntpdate-ifup [16:03] to have been hung [16:03] jodh, that 'last spoken tab completion' thing causes problems when both smb and i are talking [16:03] i often say things to myself in that situation [16:03] smoser, Hey I haven't said a thing today. :) [16:04] smb: we can hear your thoughts! [16:04] slangasek, sorry. test@cf96b6aab6fe4ca8943422ee34fbca4b.cloudapp.net [16:04] md5 hostnames for the win! [16:04] jodh, must be a lot of ing [16:05] smb: hey, I like techno :) [16:05] :) [16:05] smoser: 'status mountall' -> stop/waiting; what do you see here that points to filesystem not having fired? [16:07] slangasek, well, i think i have retracted that thought [16:07] but [16:07] $ ls -altr /var/run/landscape [16:07] ls: cannot access /var/run/landscape: No such file or directory [16:07] S45landscape should have created that. [16:07] so it would seem it didn't run [16:08] smoser: if you run the script manually, what do you get? [16:09] i haven tried. cause i didn't want ot ruin state [16:09] I see that the script will exit before creading the pidfile if check_config() failed [16:09] ah. ok. then maybe i'm barking up the wrong tree then. [16:09] why would lockfile hang ? [16:09] the 2 instances i see hung like this have a lockfile pid hung [16:10] manish, jbicha I think I've got it. Just cleaning it up. [16:10] smoser: /etc/default/landscape-client doesn't exist; therefore RUN==0, CLOUD==0, and landscape-client won't start [16:10] good enough. [16:10] lockfile ? [16:11] not sure [16:11] strace? [16:11] futex(0x7f06a7d1f720, FUTEX_WAIT_PRIVATE, 2, NULL [16:11] looking pretty broken [16:12] oh. the other thing . the otriginal thing that lead me to thinking filesystems hadnt been emited. [16:13] cloud-init-config.conf hasn't run (or if it did, it didn't successfully log anything to /var/log/cloud-init.log) [16:13] hm.. [16:13] i dont know [16:13] i'm messed up. [16:14] wait it did. [16:14] i'm sorry. [16:15] smoser: so if I run lockfile-create directly under strace, it gives me this: [16:15] open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = 5 [16:15] writev(5, [{"*** glibc detected *** ", 23}, {"lockfile-create", 15}, {": ", 2}, {"malloc(): memory corruption (fas"..., 34}, {": 0x", 4}, {"00000000023e8100", 16}, {" ***\n", 5}], 7*** glibc detected *** lockfile-create: malloc(): memory corruption (fast): 0x00000000023e8100 *** [16:15] ) = 99 [16:16] rather rude of it to write to /dev/tty, I think [16:18] cmdline has 'console=tty1 console=ttyS0' [16:18] and that is probably coming through a console output job i suspect [16:18] maybe ? trying to come up with some reason for it to be doing that. [16:20] no, the console settings don't explain why it would open /dev/tty which is the generic device === sraue_ is now known as sraue === salem_ is now known as _salem [16:46] hallyn: jdstrand: shadow with user name space support is in the archive ;-) [16:51] neat [16:51] sarnold: ^ [16:52] jdstrand: woo :) [16:52] xnox: thanks :) [16:52] hallyn: thanks :) [16:57] xnox: woot, thanks! [17:00] that's quite a party =) [17:01] yay! === _salem is now known as salem_ [17:47] infinity: upstream found the plymouth problem... no prototype for ply_get_timestamp() means that the double being returned by the function plays silly buggers with the floating point state [17:47] apparently we ought to be building plymouth with -Werror ;) [17:48] slangasek: wow... [17:48] slangasek: Ah-ha. [18:13] root@ubuntu-phablet:/# dpkg -S /etc/rc6.d/S31umountnfs.sh [18:13] dpkg-query: no path found matching pattern /etc/rc6.d/S31umountnfs.sh [18:13] does anyone know from the top of his head where that comes from ? [18:14] (base)adconrad@cthulhu:~$ dpkg -S /etc/init.d/umountnfs.sh [18:14] initscripts: /etc/init.d/umountnfs.sh [18:14] ogra_: Following the symlink would help. :) [18:14] oh [18:14] silly me [18:14] i should have looked in init.d [18:14] i wonder how even it would be to divert it ... it causes issues on phones [18:15] *evil [18:15] (reboot hangs at times) [18:15] Perhaps sorting out WHY it causes problems would be good. [18:16] well, we will hopefully not offer nfs cloud access via mobile data :) [18:16] but yeah, if i could find that out i'd be happy as well [18:16] Sure, but it does a bit more than the name would imply. [18:16] So, it would be good to sort out what's breaking. [18:17] As it may also affect other LXC setups or even normal desktops in some cases, etc. [18:17] http://paste.ubuntu.com/5808502/ is the processlist of a hanging boot [18:17] http://paste.ubuntu.com/5808513/ is the tail end of syslog [18:18] sh -x /etc/rc6.d/S31umountnfs.sh stop ? [18:18] Oh, wait. [18:18] It's the very end that's hanging. [18:18] So, blame it on upstart. [18:19] Indeed, that's not the only initctl call that's hung. [18:19] right [18:19] So, yeah, that's something we really should want to fix, not hackishly work around. [18:20] I'd recommend filing an upstart bug and poking jodh and stgraber. [18:20] well, i would like to work around it for dogfooders ... indeed i did plan to research the cause and get it fixed [18:20] ogra_: The problem I have with workarounds is that they seem to persist for two years before anyone notices and backs them out again. [18:20] heh [18:21] or even become permanent [18:21] for the phone stuff i have all of them in the lxc-android-config package ... and i expect the workaround part to be empty by release :) [18:21] Anyhow, that's pretty clearly either an upstart bug, or a self-imposed mess due to container madness. [18:21] so if it's hanging on the emit for unmounted-remote-filesystems, that's because a job that's start on unmounted-remote-filesystems won't return [18:21] i doubt the container is involved [18:22] stgraber: There's also a hung "initctl emit deconfiguring-networking" in his ps output. [18:22] stgraber, why would we have such a job ? [18:22] stgraber: http://paste.ubuntu.com/5808502/ if you missed it. [18:22] right, same thing, unless you call emit with --no-wait, a broken job can make the emit hang [18:22] it's by design [18:23] I suspect that doesn't want to change to --no-wait in either case, before someone hunts down what's halting the process. [18:23] so it's typically an issue with whatever job is started on that event more than upstart's fault (or maybe it's a case where we want it non-blocking, though for those two, I doubt it) [18:23] yeah, I think we want those shutdown related events to be blocking as they're there to cleanly bring things down and unmount network fs before the kernel cuts the power [18:24] in that ps dump, the problem appears to be dbus [18:25] dbus is supposed to stop on deconfiguring-networking and based on that ps, it didn't [18:25] right [18:25] thats why NM respawns [18:25] (in the syslog above) [18:26] i dont see much in the upstart log for dbus apart from moaning about no whoopsie user being present [18:27] but i think thats from startup anyway [18:27] just looked a bit closer, unmounted-remote-filesystems causes networking to stop which causes deconfiguring-networking to be emitted which should cause dbus to go away and the system to shutdown [18:28] so it looks like if we can figure out what's keeping dbus from stopping, the whole thing will be solved, all the blocking events will return and the system will shutdown [18:30] ogra_: btw, shutdown works fine here on mako, though that's a slightly older image (I don't appear to have powerd) [18:32] stgraber, ogra_: yes, those events are absolutely supposed to be blocking; the whole reason they exist is to ensure ordering of shutdown, making them non-blocking would reintroduce races :P [18:34] stgraber, it mostly seems to happen on maguro and also only every nth boot [18:34] though i think awe said he also saw it on mako [18:35] ogra_, ack [18:37] slangasek, into the races we have you mean ? [18:37] :P [18:38] ogra_: well, the standard Ubuntu shutdown scripts are race-free, so whatever races you're seeing are bugs in your stuff ;-) [18:39] right, seems something keeps dbus alive [18:39] keeps it alive, or respawns it somehow? [18:40] hard to tell [18:40] the info in the upstart dbus.log is pretty sparse, it doesnt show it respawned === hggdh_ is now known as hggdh [18:41] only moans about whoopsie absence [18:42] Unknown username "whoopsie" in message bus configuration file [18:42] to be exact [18:42] (and indeed it is right, no whoopsie on the phones) [18:44] ogra_, you might need to run upstart with --verbose or --debug to catch the respawning... [18:45] or just run 'initctl log-priority info' after boot [18:45] awe, well, i rather would think i want a verbose dbus that logs somewhere [18:45] and this won't be logged to /var/log/upstart/dbus.log in any case, as that just captures the log output from dbus itself - it does not give you any information from upstart about the job respawning, etc. [18:45] ogra_: which image first introduced this problem? [18:46] i think tony reported it with his first test of flipped [18:46] i havent seen it until today [18:48] ok [18:48] which devices is it seen on? [18:48] maguro more often than mako [18:48] ok [18:48] i have never seen it on grouper [18:49] oh, wait [18:49] doesnt powerd use dbus ? [18:49] ogra_: yes [18:49] its in the processlist as well [18:50] what does that have to do with the dbus shutdown being blocked? [18:50] powerd has no "stop on" stanza [18:50] so? dbus shouldn't care [18:50] hmm [18:50] that just means dbus will stop, and powerd will be left crying in the dark [18:50] it's the things that *do* have 'stop on stopping dbus' that are going to be the problem [18:51] oh, right [18:59] root@ubuntu-phablet:/# stop dbus [18:59] stop: Job has already been stopped: dbus [18:59] root@ubuntu-phablet:/# ps ax|grep dbus [18:59] 515 ? Ss 0:00 dbus-daemon --system --fork [18:59] ... [19:02] ogra_: 'status dbus'? [19:02] ogra_: that means it's busy shutting down and not stopped yet [19:02] ogra_: if it was really stopped and all events processed, you'd get "stop: Unknown instance:" [19:02] root@ubuntu-phablet:/# status dbus [19:02] dbus stop/stopping, process 515 [19:03] ah, k [19:03] right, so stuck in the stopping event as we suspected [19:04] * ogra_ adds some verbosity to dbus [19:04] i bet now i cant reproduce the issue anymore ... :P [19:06] what jobs are 'stop on stopping dbus'? [19:08] http://paste.ubuntu.com/5808713/ [19:08] ogra_: can you also paste a full "initctl list" when the system's stuck [19:08] likely something in the session then, but i dont see anything running [19:08] wow, trying to turn on -Werror for plymouth is spectacular fail [19:09] why is upstream building with -Wall by default and not cleaning up the resulting warnings? [19:09] http://paste.ubuntu.com/5808716/ [19:09] ogra_: ofono stop/killed, process 864 [19:10] it's all awe's fault ;-) [19:11] slangasek: It seems that some people don't make the jump from -Wall to "I should fix those". [19:12] slangasek: I've been helping a friend off and on with his CompSci homework, where one prof insists they always build with -Wall. The comment he got back after a few assignments was "you're the only student who actually makes sure everything builds cleanly and addresses all the warnings". [19:12] slangasek: Perhaps because I made him do so. [19:12] :) [19:13] my fault?? ;D [19:13] awe: ofono is refusing to die on shutdown, which blocks dbus, which blocks /etc/rc6.d [19:13] slangasek: well, actually it looks dead, I'm wondering if it's not a expect fork vs expect daemon issue [19:13]