[09:02] <soren> I have a qemu process on Trusty that doesn't respond to SIGKILL. Any good ideas? I don't see any bugs reported about this.
[09:03] <YamakasY> ok, so my whole mem is filled up but top doesn't show it
[10:55] <OpenTokix> soren`: I had that exact problem yesterday
[10:55] <OpenTokix> soren`: Had to powercycle that machine
[10:59] <solo1> http://paste.ubuntu.com/11669695/
[11:05] <solo1> http://paste.ubuntu.com/11669695/
[11:11] <OpenTokix> solo1: You just pasted your link a second time? Why?
[11:11] <OpenTokix> solo1: I think you have to give some other information to
[11:17] <rbasak> jamespage: need a place to coordinate with kickinz1 on the docker backports. Could you create a docker PPA in ~ubuntu-server for me please? Or would somewhere else be appropriate?
[11:18] <rbasak> kickinz1: https://code.launchpad.net/~ubuntu-server/+git/docker-backport-tools
[11:23] <rbasak> kickinz1: https://git.launchpad.net/~ubuntu-server/+git/docker-backport-tools/tree/all
[11:29] <rbasak> kickinz1: reverse-depends
[11:51] <Sling> why isnt mirror://mirrors.ubuntu.com/mirrors.txt in sources.list by default :(
[11:51] <Sling> would make more sense than the us mirror for all installs
[11:51] <kickinz1> rbasak, thanks
[11:52] <kickinz1> ls
[11:53] <rbasak> kickinz1: https://launchpad.net/~racb/+archive/ubuntu/docker/+copy-packages
[12:13] <TheEagerPadawan> anyone around here that holds the lpic-2 cert?
[12:56] <Sling> http://paste2.org/DCsKdPAW what am I doing wrong here?
[12:57] <Sling> or maybe this package is 32-bit only... hmm
[12:58] <Sling> linux32 ./configure seems to work
[14:39] <dannf> rbasak: hey - have you had a chance to look at https://code.launchpad.net/~dannf/ubuntu/wily/mysql-5.6/lp1427406 ? wanted to see if you were cool w/ the patching method
[14:42] <rbasak> dannf: sorry, looking now
[14:43]  * dannf stole that method for edk2 fwiw
[14:44] <rbasak> dannf: completely happy with the method - looks ideal
[14:44] <rbasak> dannf: it might be worth explaining somewhere why we've chosen to make the patch arch-specific though. Maybe in the changelog, or in a comment in the rules file or something?
[14:45] <rbasak> dannf: but +1 for upload to Ubuntu
[14:45] <dannf> rbasak: good point, i'll do that. other than, the last bit i'm working on is testing on powerpc (32-bit) to see if i can reproduce there
[14:45] <dannf> cool, will do after that testing. ta!
[14:45] <rbasak> ack, thanks.
[15:06] <strikov> dannf: oh, that's really good to see that we have this issue sorted (at least at some point) now; good job dannf
[15:09] <dannf> thanks strikov ! yeah, still have the copyright assignment problem preventing it from going upstream, but at least ubuntu can limp along :)
[16:00] <rbasak> squisher: around? Just looking at bcache-tools now.
[16:14] <smoser> smb, i can get you access to system and you can deploy it and watch its log.
[16:15] <smoser> basically all we do is deploy to /dev/<device>, chroot apt-get install multipath-tools-boot; unmount everything; reboot
[16:15] <smoser> this system seemed to have been happy on reboot after first one was angry.
[16:15] <smoser> but other times reboots didnt cure the ill
[16:15] <smb> smoser, or you could give me a log when it happens to you again. Which would not require me to figure out how and with which versions MAAS you do that deploy?
[16:16] <smoser> i did giv eyou a log
[16:17] <smoser> i can give you access to the system and let you deploy it.
[16:17] <smoser> https://launchpadlibrarian.net/208389797/my.log
[16:17] <smb> smoser, you gave me a log from the boot after deploy (if I understood correctly)
[16:17] <smoser> right.
[16:17] <smoser> what do you want a log of ?
[16:18] <smb> The deploy run itself. If that is even possible
[16:19] <smb> Because that boot seems just to run into a corruption that probably existed on disk before. And maybe sometimes fsck can fix that
[16:19] <smoser> the first time i noticed it, i fsck'd painfully from initramfs
[16:19] <smoser> and still had errors later on.
[16:20] <smoser> i'll deploy the node with vivid and get a log.
[16:22] <smb> smoser, Great. Thanks!
[16:50] <strikov> smb: could this corruption be related to the fact that we install the system to one of paths (say /dev/sda) but not to /dev/mpathN?
[16:51] <smb> strikov, No that is completely valid
[16:52] <smb> In fact this looks to be the way those systems are provisioned  right now without updated curtin
[16:53] <strikov> smoser: smb: are we sure that this is vivid-kernel related thing but not vivid-multipath-tools/vivid-dm related one?
[16:53] <smoser> smb, right. that is how they work without the update.
[16:54] <smoser> but with the update, we basically then just install multipath-tools-boot and expect it to work.
[16:55] <smb> strikov, the multipath target and balancers are part of the kernel so it still could be both. But since it is a failover setup those systems practically only use the one device after
[16:56] <smb> smoser, yeah, this should be a valid approach and I manually did that without issues like this
[16:57] <smb> If things go bad it were rather the unable to find a complete device type of errors
[16:57] <smb> not fs corruption
[16:57] <smoser> right.
[17:00] <smb> smoser, strikov, So one detail you may want to add to multipath.conf is to change the scsi_id call into one that includes the '-u' option. That replaces spaces in the wwids with an underscore. This somewhat was working better for me
[17:00] <smoser> smb, we do that.
[17:00] <smb> Ah ok
[17:01] <smoser> and that should be fixed in the future
[17:01] <smoser>  https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1432062
[17:04] <smb> smoser, OK. Right, somehow in my memory that was the default at least a long time ago... But I may remember incorrectly.
[17:05] <smoser> smb, well it is repoted fixed by that patch. (that is not in ubuntu yet)
[17:05] <smoser> but does strikov reported it worked for him
[17:07] <smb> smoser, Oh actually that works the other way round by letting the other pieces handle spaces. While I usually just went and set the getuid_callout in multipath.conf to use -u for scsi_id and not have spaces in the first place
[17:07] <strikov> smoser: i didn't test the patch proposed in the bug, i just verified that with 'user_friendly_names' we don't suffer from spaces because names look different (like mpath0-part1 not <serial-with-spaces>-part1)
[17:11] <squisher> rbasak, ping
[17:11] <squisher> s/i/o/
[17:12] <smoser> strikov, oh. i thought you actually built and tested that.
[17:13] <strikov> smoser: i can do that tomorrow morning
[17:13] <smoser> strikov, nah. dont worry.
[17:58] <rbasak> squisher: o/
[17:58] <rbasak> squisher: I'm finished for the day so am in and out right now, doing DIY.
[17:58] <rbasak> squisher: it all looks good. One question and one comment I think.
[17:59] <rbasak> squisher: you're using "git archive" to generate the tarball artifact for pristine-tar I presume? I think I'm fine with that given that upstream do nothing else but jamespage will probably ask.
[18:01] <rbasak> squisher: your commit 2f15970ecc04b37e965097807117765368524062 added a spurious whitespace change to an unrelated patch. Please avoid that if you can, but no worries about it this time.
[18:01] <rbasak> squisher: +1 for upload.
[18:01] <squisher> rbasak, yeah I don't know what happened with the white space
[18:01] <rbasak> jamespage: please could you sponsor commit 057b6a854342266cfb60bcd0ccd0567a46b22b24 from bcache-tools Debian VCS?
[18:01] <squisher> I use gbp pq since the beginning
[18:02] <rbasak> squisher: only two changes from upstream between 1.0.7 and 1.0.8 it looks like? Are we still having issues getting upstream stuff committed right now?
[18:02] <squisher> great, thanks, I think it's nice to close those bugs :)
[18:02] <rbasak> squisher: thanks for sorting them :)
[18:02] <rbasak> squisher: I looked at the BTS to see what else might need a clear up with the intent of doing them at the same time, but you'd already done them :)
[18:02] <squisher> sorta, the ML seems pretty dead and the main author seems to be working on some sort of next-gen tools I think
[18:03] <squisher> rbasak, :)
[20:16] <teward> sarnold: rbasak: if I see ONE MORE BUG on "Subprocess failed to install" on nginx without useful data my head's gonna explode
[20:17] <teward> apache apparently is default installed everywhere and it breaks everything :/
[20:17] <teward> sarnold: rbasak: ^ with regard to https://bugs.launchpad.net/bugs/1463383 and the thousand other ones like it
[20:17] <hexch> Hi I have an problem with isc-dhcp-server, I have 1 dhcp server for all my 1000 vlans, and problem is that it is giving clients ip from the first subnet.
[20:17] <hexch> I have on my cisco switched enabled ip-helper
[20:17] <sarnold> teward: does that mean you need to COnflicts: with apache?
[20:18] <teward> sarnold: if and only if apache is already installed
[20:18] <teward> sarnold: the last four email issues on this the default Apache conflicts with Nginx, they both try and bind :80
[20:18] <teward> which of course blows up
[20:18] <teward> sarnold: I need the server manifests including the Amazon images documented, and information told to me whether Apache is actually installed
[20:19] <sarnold> what's really annoying is I could see wanting both apache -and- nginx installed on one system. and the default "listen on 0.0.0.0:80" business is just gonna be annoyuing...
[20:19] <squisher> the conflicts seems rather harsh: you can certainly use ngix and apache side by side
[20:19] <sarnold> squisher: exactly :(
[20:20] <squisher> possibly use a post-inst script which updates the default configuration not to listen on 80 if something else is?
[20:21] <teward> on a default 15.04 with no other config options
[20:23] <teward|foobar> okay, so, i have no idea where my bouncer left off
[20:24] <sarnold> teward|foobar: you had an excess flood quit immediately after < teward> on a default 15.04 with no other config options
[20:24] <teward|pc> sarnold: the issue is not that Apache and nginx conflict - it's that they both try to bind to 80 in a default instance
[20:24] <teward|pc> sarnold: yeah, i kinda flooded the system with rage briefly
[20:24] <teward|pc> sarnold: the issue goes back NOT to the need of a conflicts: but the fact they both in a default setup bind to 80
[20:24] <teward|pc> the PROBLEM is, this is new as of 15.04
[20:25] <teward|pc> and ther'es no useful information in the already included apport data to debug what the cause of the failure on install is
[20:27] <sarnold> teward: can you change the scripts to something like service restart nginx || true;  to avoid the bugs/
[20:30] <teward|pc> sarnold: i'll look into what's run after installation, my guess is yes, we can get past it, but ideally systemd and apport would be less stupid and provide the output
[20:31] <sarnold> teward|pc: the trouble is, it's a script that's not supposed to make any output anyway. I've thought before it's a real shame there's so many failing postinst scripts but zero debugging information for any of them :(
[20:31] <teward|pc> sarnold: Job for nginx.service failed. See "systemctl status nginx.service" and "journalctl -xe" for   <-- this is during the Configuring... step
[20:31] <teward|pc> sarnold: indeed, but we may just need an apport hook that puts out those data
[20:31] <teward|pc> but iirc there's no way to say "If it fails to configure"
[20:31] <teward|pc> fail to install is a different bug in the terminal output
[20:31] <teward|pc> fail to configure is another
[20:34] <teward|pc> sarnold: i should really poke -devel and get in touch with an apport hooks expert, and try and incorporate one for the nginx package...
[20:34] <teward|pc> because it's really needed at this point
[20:35] <sarnold> teward|pc: indeed, but you might not get the output you want. knowing what is bound to port 80 might go a very long way thuogh :)
[20:40] <teward|pc> sarnold: the past 5 directly emailed issues on this were Apache
[20:41] <teward|pc> sarnold: hence why I'd like a manifest of what's on the Amazon images, as well as whatever the other stuff cloud touches or our server images default-install (when we skip tasksel)
[20:41] <teward|pc> if the Apache binaries end up on there by default, then we need to smack the images back to the stone age
[20:41] <teward|pc> and remove Apache defaultinstall
[20:41] <teward|pc> because that's SourceOfProblem
[20:42] <sarnold> teward|pc: meh, if it's installed where it wasn't before, it was because someone wanted it :)
[20:42] <teward|pc> sarnold: and therein lies the problem - Admin Error
[20:43] <teward|pc> sarnold: from https://launchpadlibrarian.net/208651215/DpkgHistoryLog.txt though I don't see apache on there (that's the bug i mentioned earlier)
[20:43] <teward|pc> although the problem would exist with lighttpd and others too
[20:43] <teward|pc> they all try and default-bind to *:80
[20:43] <teward|pc> which explodes all the things
[21:08] <teward|pc> sarnold: however, the only tricky part of this, is that 15.04 seems to be the start of all the issues - and systemd further complicated the issue :/
[21:25] <squisher> teward, hm, I've seen changes in the error reporting from start-up scripts in debian (sysv->systemd)
[21:25] <squisher> maybe it's something along that line?
[21:25] <squisher> (like what wasn't fatal before, is now considered fatal because systemd is more strict?)