[14:47] <Ussat> So, I know this is Ubuntu Server, but just a FYI, if anyone has RHEL / Centos Servers, DONT PATCH NOW:  https://pastebin.com/uGgCmVsQ
[15:39] <tomreyn> Ussat: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509
[15:39] <Ussat> NIce
[15:39] <Ussat> Ya I have put off all patching untill confirmed fixes
[17:31] <Amadex> Hellou :D
[18:42] <rangergord> Ussat, if that package had been a snap, it would have auto-updated and you'd be screwed
[18:43] <rangergord> stuff like this is a great example were complaining about inability to disable automatic updates of snaps
[18:43] <rangergord> frankly it's almost insulting for Canonical to insist on this
[18:43] <oerheks> one can schedule snap updates.
[18:44] <rangergord> you mean defer for a short period of time
[18:44] <rangergord> can I tell it "don't update this package unless I tell you to?" No.
[18:45] <rangergord> to me, a snap == rolling distro. LTS stops having any meaning.
[18:45] <oerheks> yes; refresh.hold: delays the next refresh until the defined time and date
[18:46] <rangergord> can I set that date to 2030? When I followed the discussion on launchpad, the dev insisted it's their philosophy not to let you defer by more than a couple of weeks.
[18:46] <oerheks> seems like you are just parrotting
[18:47] <rangergord> I'm parroting the Canonical dev working on snapd
[18:47] <rangergord> (one of them)
[20:28] <DammitJim> since what LTS version did we make apt the standard instead of apt-get or do I have that backwards?
[20:28] <sarnold> apt is the new front-end
[20:29] <oerheks> both are valid.
[20:29] <DammitJim> sarnold, since when? I'm trying to come up with standards at my office as to what we should use but I also don't want people to get confused
[20:29] <DammitJim> we still have Ubuntu 16 servers
[20:29] <oerheks> apt is just superiour.
[20:29] <DammitJim> what I'm starting to run into is apt is more robust and has more options
[20:29] <sarnold> DammitJim: apt is better for interactive use; apt-get is better for scripted ues
[20:29] <DammitJim> is apt-get looked down upon?
[20:29] <DammitJim> our scripts all use apt-get
[20:29] <sarnold> DammitJim: apt upgrade is far safer than apt-get dist-upgrade, and handles more conditions than apt-get upgrade
[20:29] <oerheks> The reality is that the first stable version of apt was released in the year 2014 but people started noticing it in 2016 with the release of Ubuntu 16.04
[20:30] <DammitJim> and that was one of the things I was going to ask my team to start changing
[20:30] <oerheks> https://itsfoss.com/apt-vs-apt-get-difference/
[20:30] <DammitJim> so, if I said.. hey guys, from now on (now that we finally put to sleep the last Ubuntu 14 server) we are using apt instead of apt-get, I won't run into any inconsistencies, right?
[20:30] <oerheks> nope, you are fine.
[20:31] <oerheks> when some dependensie issue pop up, apt install -f
[20:31] <DammitJim> why did you feel you needed to make that last comment about apt install -f?
[20:32] <oerheks> see apt vs apt-get, apt-get does not solve those issues on that level
[20:33] <DammitJim> what? apt-get still has a lot more functionalities to offer than apt? (per the link)
[20:33] <DammitJim> hhhmmmm... maybe I should stick with apt-get and not complicate things
[20:34] <oerheks> no, but an interesting conclusion
[20:34] <oerheks> you have no need to edit your scripts now, indeed
[20:34] <DammitJim> ok, thanks!
[20:50] <sdeziel> sarnold: the link from oerheks says that 'apt-get dist-upgrade' is replaced by 'apt full-upgrade'. Being an all time user of apt-get dist-upgrade, I'd like to know which replacement is better and for what reasons ;)
[20:53] <sarnold> sdeziel: hah, good question. I'm sure someone here's told me once before what full-upgrade does that's better than dist-upgrade but I've forgotten :(
[20:54] <sdeziel> dang... it's OK
[20:54] <sdeziel> thx
[21:04] <Ussat> rangergord, re: snaps, I rip them totally out of all my installs
[21:06] <oerheks> without snapd, no livepatch for you.
[21:43] <Aison0> Why is isc-dhcp-server accessing the ldap server? I have many of those messages: audit: type=1400 audit(1596185703.828:9389): apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/dhcpd" name="run/slapd-inetserv.socket" pid=97436 comm="isc-worker0000" requested_mask="wr" denied_mask="wr" fsuid=110 ouid=0
[21:45] <sarnold> Aison0: wild guess, is your nsswitch configured to do lookups for something through ldap?
[21:45] <sdeziel> Aison0: is this when dhcpd starts up?
[21:45] <Aison0> Aison0, yes
[21:45] <Aison0> I'm using nssswitch to lookup ldap user/groups
[21:47] <Aison0> sdeziel, no, it happens regularly. dmesg is completele spamed with the message above
[21:49] <sdeziel> Aison0: hmm, I'd probably strace dhcpd's PID around the time those audit messages/Apparmor failures get logged
[21:50] <sdeziel> I can't think of anything obvious that would explain why dhcpd would do LDAP lookups
[21:50] <sdeziel> Aison0: maybe pastebin your nssswitch.conf?
[21:51] <Aison0> https://paste.ubuntu.com/p/CTBgmGF5tR/
[21:51] <sdeziel> hosts:          files dns ldap
[21:52] <sdeziel> that's possibly why it's trying to reach out to LDAP
[21:52] <sdeziel> potentially trying to do a reverse DNS lookup or something
[21:59] <Aison0> hmm
[21:59] <sdeziel> or potentially trying to resolve forward DNS from the config?
[22:00] <sdeziel> strac'ing should tell you
[22:24] <Aison0> damn connection...
[22:26] <sarnold> Aison0: the last we saw was: < Aison0> hmm  and you might have missed: < sdeziel> or potentially trying to resolve forward DNS from the config?  < sdeziel> strac'ing should tell you
[22:26] <Aison0> thx
[22:26] <Aison0> I disabled ldap for hosts
[22:26] <Aison0> maybe that's it
[22:26] <sarnold> any success?
[22:27] <sdeziel> could also be used for the networks and aliases lookup. I honestly don't know what those are :/


[04:04] <tjaalton> huh?
[04:08] <tjaalton> RAOF: i don't recall seeing that before
[04:11] <RAOF> tjaalton: Hm. I thought you were talking on #intel-gfx about some hardware context not being there?
[04:14] <tjaalton> wwll bdw has bugs, but i bet this is with something older
[04:24] <tjaalton> https://bugs.freedesktop.org/show_bug.cgi?id=75723 it seems
[04:24] <ubot2> Freedesktop bug 75723 in Drivers/DRI/i915 "(regression since Linux 3.14?) brw_get_graphics_reset_status: Assertion `brw->hw_ctx != ((void *)0)' failed" [Normal,New]
[04:27] <RAOF> Ah.
[04:33] <tjaalton> love how it's been opened a month ago with zero interest
[05:40] <ppisati> yo
[06:58] <tjaalton>  µ’
[07:08] <smb> n'?
[07:09] <tjaalton> cat
[07:09] <tjaalton> explains all typos from me
[07:10] <smb> heh :)
[07:10] <smb> Luckily mine stays outside (unless I fail to prevent him) normally
[07:16] <amitk> i read that as "micro tic" which is close to a router company "microtik" or a new way to wave on IRC ;)
[07:23] <tjaalton> whatever works :)
[07:47]  * apw yawns
[07:53] <smb> apw, Caution there are giant bees approaching from Australia
[07:55] <soren> smb: Yet he comes back?
[07:55] <soren> smb: (re: The cat, not the bees)
[07:56] <smb> soren, Ah, I was wondering. Yes, he does. Apart of being his can opener, he thinks he has to inspect all rooms from time to time
[07:57] <soren> smb: Interesting.
[07:57] <soren> smb: I just thought cats were smarter than that. If he wants to go out, but coming into your house means being prevented from going back out, I'd assume he'd not come back.
[07:57] <soren> smb: That's the argument I use with my wife for letting our cat out whenever he wants. :)
[07:58] <smb> soren, He is smart enough to actually make use of many people. So he isn't owned by anyone but gets treats everywhere
[07:59] <smb> Its a shared cat
[08:01] <soren> smb: Clever.
[10:40] <erle-> how can i monitor actual cpu frequency (as opposed to nominal cpu steps, e.g. while running overclocked or using turbo mode)
[10:43] <apw> erle-, sudo cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq has instantaneous levels
[10:44] <erle-> apw, that one only tells me nominal states
[10:44] <erle-> but i found the solution in the meanwhile
[10:44] <erle-> from packe linux-tools the command turbostat
[10:44] <apw> ok good
[10:46] <ogra_> i thought you need to look at scaling_cur_freq for the realtime data
[10:47] <erle-> ogra_, both only display the steps of 800,1600,2400 and 3200
[10:48] <erle-> ogra_, i run at 3712 (highest regular step) and 4176 (turbo)
[10:48] <erle-> bios tells me
[10:48] <erle-> i want to know whether linux uses the turbo
[10:48] <erle-> (AMD turbo
[10:48] <erle-> )
[10:57] <erle-> does anybody here have experience with amd turbo core?
[10:58] <erle-> i disabled 4 of 6 cores in bios and overclocked, because i want to run a hard single-threaded simulation
[10:58] <erle-> turbo core requires half of cores to be idle
[10:58] <erle-> do disabled cores count as idle?
[14:14] <ogra_> is there a way to dynamically raise the ringbuffer size ? i try to debug some boot stuff, but by the time i can read dmesg or kern.log the buffer is already overwritten
[14:16] <apw> ogra_, yeah there is a kernel parameter for that
[14:16] <ogra_> remember which ?
[14:17] <henrix> ogra_: kernel-parameters.txt talks about log_buf_len
[14:17] <henrix> (never used it myself)
[14:17] <apw> log_buf_len = bytes i think
[14:18] <ogra_> henrix, thanks !
[14:18] <ogra_> will try
[14:18] <rtg> ogra_, no spaces around the ' = '
[14:19] <ogra_> yeah
[14:19] <apw> rtg, there is habit for you
[14:57] <cking> and it needs to be a power of 2
[15:43] <henrix> rtg: do you remember if chiluk was hitting this issue on T only?
[15:43] <henrix> rtg: maybe i discarded these patches from 3.11 stable too early...
[15:44] <henrix> although the backport could be non-trivial
[15:46] <rtg> henrix, pretty sure it was on T
[15:46] <henrix> rtg: ack
[15:47] <rtg> henrix, I'm not sure those VFS patches would be right for 3.11
[15:48] <henrix> rtg: yeah, i dropped them, but i admit i didn't tried too hard to understand the issues they solve... :-/
[15:50] <rtg> henrix, it might just be the namespace mount point proliferation problem. I wonder if hallyn would know.
[15:54] <hallyn> ?
[15:54] <rtg> hallyn, these commits in 3.14:
[15:54] <rtg> 38129a1 switch mnt_hash to hlist
[15:54] <rtg>  0b1b901 don't bother with propagate_mnt() unless the target is shared
[15:54] <rtg>  1d6a32a keep shadowed vfsmounts together
[15:54] <rtg>  0818bf2 resizable namespace.c hashes
[15:55] <rtg> do they help the performance of removing mount points ?
[15:55] <hallyn> sorry i haven't seenthem
[15:55] <hallyn> certainly 0b1b901 should
[15:55] <apw> rtg, was that arges' bug perhaps
[15:55] <hallyn> as should the first
[15:56] <rtg> apw, I thought it was chiluk ?
[15:56] <apw> oh maybe, perhaps i need a beer to remind me
[15:56] <rtg> apw, whoa, it _is_ about that time.
[15:57] <ogra_> way past
[15:57] <ogra_> *burp*
[15:57] <hallyn> drat i'm in the wrong tz
[15:57]  * hallyn swigs some coffee, wishing it were something else
[15:58] <rtg> hallyn, could you have a look at those commits ? They are scheduled for 3.13 stable, but I might pull them earlier and get some testing on them.
[15:58] <hallyn> rtg: meeting coming up, i'll look after that
[15:59] <rtg> hallyn, thanks
[15:59] <hallyn> np - ttyl
[16:01] <arges> hallyn: apw : yea it was chiluk's bug
[16:19] <chiluk`> rtg henriz   0818bf27c05b2   is the important one that should be included in all stable kernels.
[16:19] <chiluk`> give me a sec to take a look..
[16:20] <rtg> chiluk`, well, its not in Trusty
[16:20] <chiluk`> although the move to hlist for m_hash is not necessary
[16:21] <rtg> though it is marked for stable
[16:35] <zequence> Not at all meaning to sound negative, and also, since I'm a fan of you know who, it's SRU up your ass time again!
[16:36] <zequence> infinity: Any chance you'll be SRU'ing linux-lowlatency at next point release to a newer version? I've been meaning to try make that happen, but perhaps now I don't even need to?
[16:57] <zequence> Just to clarify, was just quoting Metallica before.
[17:53] <rtg> ogasawara, contrary to your meeting notes, I _do_ plan to upload once more before freeze, if for no other reason then to remove lttng in favor of the lttng-modules package.
[17:54] <ogasawara> rtg: oh you do?  when do you think you'll do the upload?
[17:54] <ogasawara> rtg: tomorrow?
[17:54] <rtg> ogasawara, I guess it'll have to be tomorrow won't it. Thursday my time would be too late.
[17:55] <ogasawara> rtg: ok cool, I'll see if I can squeeze in this patch I've been bisecting for
[17:55] <ogasawara> rtg: just depends on how quickly I can get this testing feedback
[17:55] <rtg> ogasawara, ack
[18:21] <hallyn> chiluk: so why is 0818bf27c05b2 important?
[18:22] <hallyn> it seems to me that commit 38129a1 is important as otherwise we risk infinite loops when racing withumounts (if the description is to be believed)
[18:22] <hallyn> and commit 1d6a32a seems to be a prereq for that one
[18:23] <chiluk> hallyn, so openstack neutron nodes keep the network processes in network namespaces and mount namespaces... unfortunately that means that for n network namespaces... there has to be n^2 entries in the mount_hashtable.
[18:23] <hallyn> commit 0b1b901 seems unimportant - we only save a lock_mount_hash (and unlock), so unless we are seeing that as a hot path somewhere...
[18:23] <chiluk> so for 4000 namespaces that means 1.6m entries in that hashtable.
[18:23] <chiluk> which becomes a serious bottleneck, and can also lead to hangs and crashing
[18:23] <hallyn> chiluk: ok andn so switching to hlist halves the size of that table?
[18:24] <chiluk> hlist isn't as important as increasing the size of the hashtable itself.
[18:24] <chiluk> but hlist would help as well.
[18:24] <hallyn> i'd be curious to see how much kmem you save then with both  38129a1 and 0b1b901
[18:24] <hallyn> uh, i mean and 0818bf2
[18:25] <hallyn> chiluk: so you would agree that commit 0b1b901 seems unimportant?
[18:26] <chiluk> well since they all are meant to improve the performance of the mount namespaces, I would think they are all important... some more than others.
[18:27] <chiluk> 0818bf2 should go into all p+ kernels imho
[18:27] <chiluk> 0818bf2 1d6a32 0b1b901 38129a13 should all go into trusty.
[18:27] <chiluk> if they don't clean cherry-pick, I'll work on a backport.
[19:13] <soren> chiluk: 4000 network namespaces? Is that a number you're making up or does someone claim to need anything even close to that?
[19:14] <soren> chiluk: It just sounds a bit over the top to me. Even with a 64 CPU system with, say, 8 VM's per CPU, you'd need an average of 8 distinct networks per VM to reach that number.
[19:17] <chiluk> soren... look at openstack .. and yes 4000 is only a small part for a decent sized cloud.
[19:18] <chiluk> it's not the compute nodes that are the problem.
[19:18] <soren> chiluk: Oh, right, the network nodes need to accommodate every single network.
[19:19] <chiluk> soren it's the network gateways... mount/net namespaces are used to partition the network by the neutron nodes
[19:19] <soren> chiluk: Gosh, yes, 4000 aren't going to get you anywhere then.
[19:19] <chiluk> exactly
[19:19]  * soren shakes his head at that horrible design
[19:19] <chiluk> right now most people scale out their gateways
[19:19] <chiluk> but some people have beefy gateways, and are pissed at the 3-4k limitation.
[19:20] <soren> chiluk: Understandable.
[19:20] <soren> chiluk: Yeah, I totally hadn't thought of the network nodes. It makes much more sense that way.
[19:21] <chiluk> with these patches those people can take the current 4k hashtable and make it 512mb or more... and get much better performance on deletion..
[19:21] <chiluk> which is usually where the problems started.
[19:21] <chiluk> it used to be a 4k hashtable with 80k node linked lists...
[19:22] <soren> Oh, it doesn't remove the O(n^2) space complexity?
[19:22] <soren> Oh, my.
[19:22] <chiluk> it does not.
[19:22] <soren> Yeah, that sounds like no fun at all.
[19:23] <chiluk> the issue with O(n^2) comes from the lack of forsite in the unshare(CLONE_NEWNS) calls
[19:23] <chiluk> and the fact that each new net namespace creates it's own mount...
[19:23] <chiluk> for proc entries.
[19:24]  * soren doesn't quite grok how that becomes an n^2 thing
[19:25] <chiluk> each namespace creates a mount... each namespace duplicates all mounts for it's namespace.
[19:26] <soren> Oh.
[19:26] <chiluk> or at least creates duplicate entries in those tables for it'a namespace.
[19:42] <hallyn> if you're doing network namespaces it's not strictly necessary to have fresh mounts ns in each netns
[20:17] <infinity> zequence: You might need to rephrase your question.
[21:02] <zequence> infinity: are you going to SRU the trusty kernel to precise later?
[21:03] <bjf> zequence, if you are asking if there will be an lts-backport-trusty kernel for precise the answer is yes
[21:03] <bjf> zequence, that is also why there will be a 12.04.5 release
[21:06] <infinity> zequence: However, the answer to the question you were really asking (does linux-lts-trusty include lowlatency) is currently "no".
[21:07] <infinity> And will probably remain no for that backport.
[21:07] <infinity> But for 14.10 kernels backported to trusty, I think we should enable all flavours.
[21:07] <zequence> infinity: Alright
[21:50] <gabriell> Hello. I'm newbie to kernel development. I'm trying to load a module I wrote, but I'm getting the error "Invalid module format". Can anyone help me with this?