[04:40] <kantlivelong> does RPCNFSDCOUNT not work in 16.04 for nfs-kernel server? it looks to me that its never used by the service unit file but the unit does use RPCNFSDARGS
[04:42] <kantlivelong> i only ask because increasing the thread count seems to make no diff
[06:44] <lordievader> Good morning
[14:52] <lucidguy> Ok, Server with 192GB of ram.  I assume that's GIGA, and not GIBI.  Convert that to Gibibytes and you get 178GiB.  If you do a free -g on the box you get 187?  I'm pretty sure df is in GiB, so why is there about 10GiB discrepancy?
[14:54] <sdeziel> lucidguy: AFAIK, RAM is expressed with a 1024 base value for "K"
[14:55] <lordcirth> sdeziel, -g is gibibytes according to the manpage
[14:55] <sdeziel> lordcirth: I'm referring to the 192GB part
[14:56] <lordcirth> Ah, the manufacturer? Yeah I don't know what they use
[14:56] <lucidguy> Ohh, so ram is sold in GiB not GiG like drives?
[14:56] <sdeziel> lucidguy: that said, that doesn't explain where the 5GB went
[14:56] <blackflow> 192GB of physical RAM but not every bit is addressable. dmesg will show available physical addressable RAM in bytes.
[14:57] <sdeziel> lucidguy: I'd check 'dmesg | grep -i memory' and see how the kernel reserved that RAM
[14:59] <sdeziel> lucidguy: on a random box here, I have: Memory: 4740848K/4914680K available (8613K kernel code, 1335K rwdata, 4028K rodata, 1484K init, 1284K bss, 173832K reserved, 0K cma-reserved)
[14:59] <lucidguy> Memory: 196455640K/199738988K available (12300K kernel code, 2473K rwdata, 4288K rodata, 2408K init, 2416K bss, 3283348K reserved, 0K cma-reserved)
[14:59] <sdeziel> lucidguy: and this VM has 4800MiB assigned
[15:00] <sdeziel> If I'm doing my maths right, your kernel only sees 190.4 GiB
[15:00] <lucidguy> sdeziel: Does that make sense?
[15:00] <sdeziel> and 3.13 GiB are 'reserved', whatever that means
[15:01] <blackflow> stack <-> heap gaps'n'all, that RAM is not addressable.
[15:01] <sdeziel> lucidguy: I don't know why the kernel doesn't see the full 192 GiB, looks like the EFI/BIOS is hiding some of it or something like that but I'm just guessing at this point
[15:02] <lucidguy> Ok, this makes more sense now.  I knew storage, like drives were in GiG and not GiB, thought RAM was sold/represented the same way.
[15:02] <sdeziel> blackflow: I would assume that only apply to virtual addresses, not physical ones, no?
[15:02] <patdk-lap> if you have some pci devices that use memory (aka video cards)
[15:02] <patdk-lap> that memory is not usable by the os
[15:02] <sdeziel> yeah ^
[15:03] <sdeziel> but 2G of video RAM on a server sounds a little excessive ;)
[15:03] <lucidguy> My last statement is accurate right?  Disks are still sold in GiG?
[15:03] <patdk-lap> I think some network cards do this also, and infiniband cards, but those are rare
[15:03] <patdk-lap> ya, I guess it has to be a real server motherboard to have 192gb ram anyways
[15:04] <patdk-lap> could need it if it was a windows server :)
[15:04] <lucidguy> Ubuntu Server
[15:04] <patdk-lap> efi/bios doesn't hide it
[15:04] <patdk-lap> hmm, that motherboard was designed for only ubuntu server?
[15:05] <lucidguy> I wonder if the BOSS storage controller is taking some
[15:06] <sdeziel> patdk-lap: do you know where the NIC/video cards reserved chunks would be visible/accounted for? Would the kernel still see that memory or not? If it does, would they be in the 'reserved' section from that dmesg line?
[15:06] <patdk-lap> the kernel won't see it, it will be subtracted before the os boots
[15:07] <lucidguy> Thanks guys, appreciate the responses, solved my mystery.
[15:07] <sdeziel> OK so that would explain where the 1.6GiB went
[15:07] <lucidguy> I'm sure I read online that ram sold was represented in GiG not GiB.. grr
[15:07] <sdeziel> one day, I hope to understand what the kernel reserves...
[15:08] <patdk-lap> well, I cannot remember how it does it now
[15:08] <patdk-lap> but should reserve <1meg
[15:08] <patdk-lap> still lots of dma stuff that only works below 1meg or 16megs
[15:08] <sdeziel> 170MiB on that i440fx VM
[15:08] <sdeziel> out of 4800MiB assigned to it
[15:09] <blackflow> sdeziel: yes, but that will always reduce the availability of physical RAM as long as physical addresspace is less than virtual (which is always unless you had gazillions of ram)
[15:10] <blackflow> oh yeah, there's the GPU as well, sometimes it shares the system RAM
[15:10] <patdk-lap> said that way above
[15:10] <blackflow> sorry, didn't see it
[15:11] <sdeziel> blackflow: I don't understand how the gap between stack and heap wouldn't be usable by the kernel. That gap is in virtual address space alone, no?
[15:19] <patdk-lap> it is
[15:19] <patdk-lap> but that doesn't really help the kernel
[15:19] <patdk-lap> if the kernel was places randomly in each process, none of it's memory pointers or anything would work
[15:20] <sdeziel> patdk-lap: I'm arguing with: blackflow: stack <-> heap gaps'n'all, that RAM is not addressable.
[15:20] <patdk-lap> define addressable :)
[15:20] <sdeziel> more specifically the 'not addressable' part
[15:20] <patdk-lap> if you use it, it will cause a exception
[15:21] <sdeziel> not addressable by the userspace process
[15:21] <patdk-lap> it is addressable
[15:21] <patdk-lap> it's not backed by anything, and needs to be allocated
[15:21] <sdeziel> what I'm saying is this gap is purely virtual, it doesn't waste any physical RAM
[15:22] <patdk-lap> well, there is some waste, but your talking on a small level, 4k
[15:22] <sdeziel> I don't understand why the gap would be allocated at all
[15:22] <patdk-lap> or maybe more for empty stack allocations
[15:22] <patdk-lap> unused stack space
[15:23] <patdk-lap> unused heap space
[15:23] <patdk-lap> and mmap
[15:23] <sdeziel> right but that's not part of the gap
[15:23] <patdk-lap> outside of that, nothing is allocated to physical or swapped ram
[15:23] <sdeziel> or is it? Is there actually a gap or can the stack and heap grow till they meet? Causing explosion
[15:24] <patdk-lap>  heh?
[15:24]  * sdeziel vaguely remembers stackclash
[15:24] <patdk-lap> of course they can grow till they meet
[15:24] <blackflow> sdeziel: ah yes, these days it's all in virtual address space only
[15:24] <patdk-lap> when all the virtual address space is used up
[15:24] <patdk-lap> the kernel will allocate physical and swap memory to back those pages
[15:25] <patdk-lap> if there isn't enough swap space, then it will blow up sooner
[15:25] <blackflow> sdeziel: they could meet in the past, there was a CVE about it, forgot the details. but iirc kernel now protects against that.
[15:26] <sdeziel> https://access.redhat.com/security/vulnerabilities/stackguard
[15:26] <blackflow> ah yes, the stack clash, you said it.
[16:27] <jamespage> coreycb: apologies - dpdk things blew out my morning today - I'll endeavour todo some of the dep updates for train m1 tomorrow
[16:48] <coreycb> jamespage: no problem at all, i'm going to focus on it this afternoon and see what deps i can get through.
[19:08] <ahasenack> rafaeldtinoco: ok, so, sponsoring
[19:09] <rafaeldtinoco> ahasenack: tks, NOW ill finally cherry-pick iproute2 patches for cosmic and disco then.
[19:10] <rafaeldtinoco> ahasenack: do I have to ping someone for the missing +1s on the review ?
[19:10] <rafaeldtinoco> (server team / etc)
[19:10] <rafaeldtinoco> or just let it hang in there
[19:10] <ahasenack> rafaeldtinoco: no, one is enough from our team
[19:10] <ahasenack> and I can sponsor
[19:11] <ahasenack> ahasenack: we usually just do a final check, like the bank asks you to ack sometihng on the phone loud and clear
[19:11] <ahasenack> rafaeldtinoco: rather
[19:11] <ahasenack> rafaeldtinoco: so, ok for having 96b1b4a6b461effe47a19d5d62d9f0e9825e9fcb sponsored?
[19:11] <rafaeldtinoco> ahasenack: +1
[19:12] <ahasenack> ok
[19:12] <ahasenack> rafaeldtinoco: two things I'll do then
[19:12] <ahasenack> rafaeldtinoco: one is push the upload tag, which marks the commit has corresponding to the dput I'll do right after
[19:12] <ahasenack> rafaeldtinoco: and second is the actual dput
[19:13] <ahasenack> rafaeldtinoco: that will upload the package to eoan-proposed, where it will go through what we call migration checks
[19:13] <ahasenack> rafaeldtinoco: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[19:13] <ahasenack> rafaeldtinoco: it may take a while to show up there after the upload, but I'd ask you to do what we call "follow its migration"
[19:13] <ahasenack> i.e., keep an eye there to see if it passes the tests and actually lands in the archive
[19:13] <rafaeldtinoco> will do
[19:17] <ahasenack> rafaeldtinoco: that page refreshes about twice an hour, it's a bit irregular
[19:19] <rafaeldtinoco> good to know
[19:23] <ahasenack> rafaeldtinoco: it's currently building: https://launchpad.net/ubuntu/+source/iproute2/4.18.0-1ubuntu3
[19:23] <ahasenack> a good hint that it migrated, and usually comes way before the excuses page updates, is the email from lp saying the bug was closed, since it's mentioned in d/changelog
[19:24] <rafaeldtinoco> ok
[19:30] <ahasenack> rafaeldtinoco: you can now also move the card to "external dependency", signaling we now have to wait for this external process
[19:30] <rafaeldtinoco> ahasenack: done
[19:30] <ahasenack> and I just assigned it to you, that was missing
[19:30] <rafaeldtinoco> hum. maybe others are missing that too, /me review
[19:39] <rafaeldtinoco> ahasenack: disco and cosmic are good also
[19:40] <rafaeldtinoco> ahasenack: are we waiting for full verification on eoan ?
[19:40] <ahasenack> ok, let's wait for eoan to migrate
[19:40] <ahasenack> yep
[19:40] <rafaeldtinoco> ok
[19:50] <cncr04s> my grub won't boot from my mdadm array anymore
[19:51] <cncr04s> some recent update broke it
[19:51] <cncr04s> its an imsm array
[20:01] <rafaeldtinoco> ahasenack: alright. so after dput to -proposed, and update_excuses are good, how does it get to -updates ?
[20:02] <rafaeldtinoco> (in ccase this was an actual sru)
[20:02] <ahasenack> rafaeldtinoco: for eoan there is no -updates yet, so it will just move to where it should be
[20:02] <rafaeldtinoco> yep
[20:02] <ahasenack> main or universe
[20:02] <rafaeldtinoco> ah gotcha
[20:02] <ahasenack> for srus,
[20:02] <ahasenack> the upload to proposed will be in an unapproved state
[20:02] <ahasenack> until a member of the sru team gets to it
[20:02] <rafaeldtinoco> ah i know where that is
[20:03] <rafaeldtinoco> all makes sense now
[20:03] <ahasenack> if it's accepted, then this person will move it to -proposed, lp will get that standard comment about it having been accepted and asking for help testing it, etc
[20:03] <ahasenack> we also have to check the excuses page for that particular ubuntu release, to see if dep8 tests failed
[20:04] <ahasenack> if there are failures, they need to be investigated, and either justified in the bug with a comment, or fixed in a subsequent upload
[20:04] <rafaeldtinoco> ok
[20:05] <ahasenack> rafaeldtinoco: the per-release excuses page is like this: https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html
[20:05] <ahasenack> replace "bionic" with your release of choice
[20:05] <rafaeldtinoco> ok, saving bookmarks
[20:05] <ahasenack> yep
[20:39] <Soni> what are alternatives to lighttpd that will fit a shitbox VPS? 1 core, 256 MB of RAM, 10 GB of disk, etc
[20:40] <Soni> I don't like the configs, I have the same block copypasted 5 times, once for each subdomain, and I wanna add a blog to it.
[20:45] <OerHeks> a blog on a vps, interesting
[20:48] <ploxiln> Soni: I use nginx a lot, it's also very efficient ... it's pretty popular so you may have already considered it
[20:49] <ploxiln> there's an "nginx-light" package with a reduced set of features enabled
[20:49] <Soni> but how hard is it to configure?
[20:49] <ploxiln> I suppose it takes some getting used to, but it can be very concise to just serve some files or just proxy. fcgi requires a separate helper like spawn-fcgi
[20:51] <ploxiln> https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/
[20:52] <sdeziel> Soni: I'd advise sticking to nginx-core which is an Ubuntu specific flavor that mirrors upstream default plugin selection, that's the one in 'main'
[20:52] <sdeziel> Soni: with that version, you get a handful of plugins that you can disable to reduce the RAM usage. Those plugins are for TCP and mail proxying
[20:57] <sdeziel> Soni: with those plugins removed, my TLS/HTTP 2.0 nginx on 18.04 takes only 5.5M of RAM ;)
[21:06] <Soni> maybe I should just use thttpd
[21:13] <Soni> hm
[21:14] <Soni> it's really hard to fit a blog engine into a shitbox VPS apparently
[21:15] <sdeziel> Soni: if 5.5M of RAM is too much for you, then yeah, you'd need to use something != nginx
[21:15] <Soni> does nginx have some plugin to turn an atom feed into an HTML blog?
[21:15] <sdeziel> Soni: the biggest RAM consumers are often the DB engine and PHP depending on your blog
[21:15] <Soni> so I edit the .atom and it changes the blog automatically?
[21:17] <sdeziel> Soni: not sure that is what you are looking for but I found this : https://ef.gy/serving-an-atom-bundle
[21:21] <Soni> okay, let's see if I can make any sense of this stuff
[21:21] <Soni> first, how do I clean the package cache?
[21:22] <Soni> actually hm is it safe to just remove everything in /var/cache?
[21:33] <sdeziel> apt-get clean
[21:33] <sdeziel> Soni: this should reclaim some space
[21:34] <Soni> sdeziel: that's only for apt tho, I have stuff like the webserver as well
[21:35] <sdeziel> Soni: I don't know your server but I'd recommend to tread carefully, rm -rf can hose a server pretty quickly ;)
[21:35] <Soni> sdeziel: so can certbot. doesn't stop me from using it.
[21:36] <sdeziel> Soni: I find dehydrated less intrusive but I guess it's a question of personal taste
[21:38] <Soni> hm I wish I knew about that before setting up certbot
[21:39] <Soni> would probably be lighter on disk usage as well
[21:41] <sdeziel> dehydrated only deps are bash and curl IIRC
[21:42] <Soni> anyway, any tool to clean up /var/cache?
[21:49] <OerHeks> !info Polipo