[05:31] <cpaelzer> good morning
[06:42] <lordievader> Good morning
[11:49] <cpaelzer> coreycb: in the preliminary qemu 2.10 rc4 the issues you mentioned (and more) are fixed - FYI https://launchpadlibrarian.net/334565303/buildlog_ubuntu-artful-amd64.qemu_1%3A2.10~rc4+dfsg-0ubuntu1_BUILDING.txt.gz
[11:56] <coreycb> cpaelzer: great, thanks
[12:06]  * ddellav waves to coreycb 
[12:07] <coreycb> hey ddellav!
[12:07] <ddellav> hi
[14:20] <cpaelzer> coreycb: beisner: hey usually (and on pike in particular) do you usually pick src:ipxe for qemu-ipxe from the latest release (artful atm)?
[14:23] <coreycb> cpaelzer: i have no idea, i imagine that would likely be a nova default
[14:33] <coreycb> cpaelzer: there's not a single hit for qemu-ipxe in nova source code if that helps
[14:49] <cpaelzer> coreycb: well I'll check the ppa - is the pike porposed public?
[14:51] <coreycb> cpaelzer: the only thing we modify in the qemu package is libseccomp-dev version in d/control. the pike-staging ppa is public if you want to take a look there.
[14:54] <cpaelzer> coreycb: it really is a different src, not qemu nor any else but ipxe
[14:55] <coreycb> cpaelzer: ah, i see
[14:57] <cpaelzer> coreycb: checked - you do not have it in cloud archive
[14:57] <coreycb> cpaelzer: ack
[14:57] <cpaelzer> well htat makes it even worse :-/
[16:14] <nacc> ahasenack: if you want to test: http://paste.ubuntu.com/25418476/ dtrt here
[16:14] <nacc> ahasenack: for that bug
[16:14] <nacc> ahasenack: your simple fix, not the more complicated one to not manipulate the current repository at all
[16:50] <nacc> cpaelzer: I believe src:libvirt should be caught up now, can you check?
[17:25] <albech> looking for some information on installing a newer verison of dovecot-sieve dovecot-managesieved than the ones being shipped with 16.04. It this possible without compiling?
[17:27] <nacc> albech: i don't see anything in backports, so unlikely. You could search PPAs with the normal caveats
[17:29] <albech> nacc: dang, thanks tho
[17:31] <nacc> albech: np
[18:00] <ahasenack> weird, postinst of grub-pc, php and samba failed in the same apt install with exit code 10
[18:00] <ahasenack> https://launchpadlibrarian.net/334576890/DpkgTerminalLog.txt
[20:13] <Hexian> I wonder if anyone who was around when I originally went through my intermittent performance is still here
[20:14] <Hexian> disabling swapping eliminated major page faults and the application performance drops that they caused, but now at random times, minor page faults are a serious issue
[20:16] <Hexian> minor page faults can cause my real time processes to freeze for over 500ms straight while user CPU time is replaced with system CPU time for that process... and it seems like it is impossible to have the kernel preload the entire application and prevent minor page faults
[20:18] <Hexian> I've eliminated almost all disk IO completely, there are zero disk reads and infrequent writes of a few KB at a time
[20:18] <Hexian> it does not seem right that minor page faults should be able to lock up processes for 500ms+ at a time, I can't help but think that either the kernel is faulty, or the hardware is
[20:19] <sarnold> buy more RAM?
[20:19] <Hexian> sarnold: more than 50% of the 32GB ram is free at all times
[20:21] <Hexian> these random minor page faults causing large process freezes are happening after the process has been running for almost a day, so it's not like it's a fresh process which is hitting memory for the first time
[20:21] <Hexian> I don't know what to do about this, it is a really serious problem
[20:24] <Hexian> any calls that block these processes for 1ms are a problem, this is causing frames that are over 800ms, which is almost entirely waiting on a minor page fault and then catching up on more than half a second of lost CPU time
[20:27] <sarnold> Hexian: o_0 you had excessive swap traffic with ~16 gigs _free_??
[20:27] <sarnold> Hexian: that feels worth a bug report
[20:29] <Hexian> sarnold: not excessive, very infrequent, but that often caused IO wait times and caused performance drops in these real time applications, by default the kernel assumes every server has a SSD and doesn't mind causing IO wait times even with plenty free ram
[20:29] <Hexian> these minor page faults are a much bigger concern though
[20:30] <Hexian> I guess I'm going to have to try downgrade the kernel a couple years and see if that helps
[20:32] <sarnold> Hexian: maybe try fiddling the 'swappiness' or whatever parameter a bit first?
[20:32] <Hexian> swappiness is set to 0, there are zero major page faults, zero disk reads (from system or applications), infrequent tiny writes (writes that are more than a few kb get made to a ram disk)
[20:33] <Hexian> disk IO is virtually non-existant
[20:33] <Hexian> minor page faults are caused when data is already loaded into ram but is not yet accessible, or something like that
[20:34] <Hexian> I have no idea why that is happening at all after hours or uptime, let alone a day uptime, or why it makes my processes lock up for over half a second to do the minor page fault system calls
[20:35] <Hexian> this happens at random times, with random severity, even outside of peak times with 30% total system CPU usage
[20:52] <lunaphyte> hi.  i've recently set up a new install of 17.04, and am having symptoms where it hangs at shutdown, complaining that it failed to unmount a number of filesystems.
[20:52] <lunaphyte> how can i troubleshoot this further?
[20:53] <ahasenack> do you have anything special in your mount points?
[20:53] <ahasenack> today I was just looking at a bug where the user had lvm over mdadm raid1 and quotas enabled
[20:53] <ahasenack> and he said something about errors during shutdown
[20:53] <lunaphyte> i don't believe i do, but let me double check
[20:55] <lunaphyte> it fails to  unmount /var/log/, /var/, /tmp/, and /home/
[20:59] <lunaphyte> here's a little bit of info: http://dpaste.com/0AMSEF9.txt
[20:59] <ahasenack> ah, btrfs
[20:59] <lunaphyte> sorry the fstab spacing is all janky
[20:59] <ahasenack> that qualifies as "special" :)
[20:59] <ahasenack> and lvm
[20:59] <lunaphyte> oh, ok :)
[20:59] <lunaphyte> i guess so
[20:59] <lunaphyte> yeah, lvm
[20:59] <ahasenack> and two vgs
[20:59] <lunaphyte> yeah
[21:00] <ahasenack> did it work in another ubuntu release?
[21:00] <lunaphyte> here's one more bit of info if it's might be helpful: http://dpaste.com/0NRC48C
[21:01] <lunaphyte> well, it's possible i'm crazy, but iirc, it was working right earlier with this install
[21:02] <lunaphyte> i haven't used this setup in a previous release though
[21:02] <ahasenack> I suggest a bug report then, with the info you provided
[21:02] <ahasenack> I don't know how to debug that in systemd
[21:03] <ahasenack> and "btrfs fi sh" probably too
[21:03] <lunaphyte> i did :) - https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1709384
[21:44] <fatdrago_> can ssh public keys be all numbers?
[21:52] <nacc> fatdrago_: well, i think the key itself is all numbers, but the base64 encoding you see in, e.g., ~/.ssh/id_rsa.pub is more than just the key, it has a header indicating that it is a key and what kind of key and is base64-encoded: https://tools.ietf.org/html/rfc4253#section-6.6
[21:53] <nacc> fatdrago_: or by 'numbers' did you actually mean the text in the public key file?
[21:57] <fatdrago_> I asked a user to generate pair of keys and she send me bunch of numbers . it don't look like rsa format to me..with all hex mixed in!
[21:58] <fatdrago_> it does say rsa-key-20170828, but it might be different system or something..all numbers!
[21:58] <sdeziel> fatdrago_: could be puttygen's format
[21:58] <sdeziel> the standard format which isn't OpenSSH
[21:58] <sdeziel> `ssh-keygen -i -f pub` should convert it to OpenSSH format
[22:00] <fatdrago_> I send her three links instructions how to generate in windows/putty and mac and linux.. let's see if she comes through and can work through the problem and convert the putty one!
[22:03] <nacc> fatdrago_: ah ok