[03:34] <genii> sarnold: I think he has some idea that because now he knows how to install thing in linux his career will be to be a sysadmin
[03:34] <sarnold> genii: aye.. it's perhaps a longer road than he suspects, but still, I want to help folks as I can :)
[03:35] <genii> Hehe, helluva long road
[03:45] <sarnold> yeah :)
[06:12] <lordievader> Good morning
[10:16] <jamespage> coreycb: I've uploaded SRU's for bionic, cosmic and disco for the neutron internal dns fixes
[12:01] <coreycb> jamespage: thanks
[13:39] <coreycb> sahid: I've merged/uploaded everything except neutron so far for bug 1830695
[13:39] <coreycb> jamespage: fyi ^
[14:13] <supaman> about the xenailxerux release notes, in it they say that PHP was upgraded to PHP7 and packages were either rebuilt or upgraded to php7, does the rebuild then take place against the new version of php5?
[14:26] <sdeziel> supaman: Xenial only ships with PHP 7.0 packages so those are all build against this version
[14:31] <supaman> sdeziel: even cakephp?
[14:32] <supaman> https://packages.ubuntu.com/xenial/web/cakephp
[14:34] <sdeziel> supaman: yes
[14:37] <TJ-> sdeziel: teward I'll leave Bug #1581864 up to you to respond
[14:43] <sdeziel> teward: do you plan to provide another PPA with the TJ's new patch? If yes I would give it a test run
[14:47] <teward> sdeziel: TJ-: yes, but right now i'm fixing a major network bug at work
[14:47] <teward> i'll upload with p1 attached to the version string I had uploaded previously so it bumps up
[14:47] <teward> give me a minute i have to fix this crap
[14:47] <sdeziel> thank you both
[14:49] <teward> ahasenack: RE: your comment about intrusive patches
[14:49] <teward> i think Upstream would want evidence it works before including
[14:49] <ahasenack> sure
[14:49] <teward> we can test-drive it in a PPA first
[14:49] <teward> if it works there then we can SRU it here and next NGINX release with it in it I can upload it to Eoan
[14:49] <ahasenack> I checked fedora, the same thing happens there, fwiw
[14:49] <teward> and drop the delta
[14:50] <teward> ahasenack: yeah it's an upstream issue, TJ ID'd it in the code
[14:50] <teward> grrr this darn network bug...
[14:50] <ahasenack> was an upstream bug even filed?
[14:50] <teward> wonder if a switch is broken... BRB
[14:50] <teward> ahasenack: I didn't see one, but we could always search Trac
[14:50] <ahasenack> ugh, trac
[14:50] <teward> most things don't end up in the Trac tracker and just on nginx-devel@
[14:54] <sdeziel> Trac is a good deterrent for bug reporters ;)
[14:56] <ahasenack> didn't want to say it, but there it is :)
[15:20] <TJ-> ahasenack: I didn't want to report a bug until we're sure we're aiming at the correct target!
[15:24] <ahasenack> TJ-: fair :)
[15:39] <teward> TJ-: PM me yoru email address to use on the DEP3 headers?
[15:39] <teward> 'cause i'm adding headers xD
[15:39] <TJ-> teward: same as last time; ubuntu@iam.tj or hacker@iam.tj
[15:40] <teward> yeah but i lost my logs :P
[15:40] <teward> thanks
[15:40] <TJ-> :p
[15:40] <TJ-> didn't keep the patch? tut tut :D
[15:40] <teward> lost the headers in my logs
[15:49] <teward> TJ-: sdeziel: PPA uploads complete, made a version snafu with Eoan in the PPA that caused the latest patch to be rejected but fixed in the PPA.  Should build 'soon'.
[15:49] <teward> p1 appended to version strings
[15:50] <teward> building: Xenial, Bionic, Cosmic, Disco, Eoan.
[16:07] <teward> TJ-: I'm fairly sure we've narrowed it down to an actual NGINX race condition problem, for how it handles PIDfiles, so... :P  In either case, the PPAs are buildilng now time for tests :P
[16:08] <TJ-> teward: it's certainly due to not creating the PIDfile in the parent process, since systemd checks for the PID file as soon that exits
[16:09] <teward> *nods*
[16:09] <TJ-> just lucky on SMP the forked child gets going and creates that before parent exits on the other thread
[16:09] <teward> looks like s390x is the only arch in the PPAs that's backlogged and the rest were built.
[16:09] <teward> right
[16:10] <xnox> teward:  odd, asking to clean them.
[16:10] <teward> xnox: heh, didn't know you were tracking xD
[16:11] <teward> xnox: ahhh i think that's because many are stuck in a cleaning loop and a few are disabled
[16:11] <teward> of the 20 s390x builders, 5 are disabled 4 are doing builds and the rest stuck on cleaning
[16:11] <xnox> teward:  tracking what? =)
[16:12] <teward> xnox: when people complain about PPA buidlers being weird :P
[16:22] <sdeziel> teward: TJ-: test successful on bionic
[16:23] <sdeziel> let me know if you want some other distro tested prior to proposing upstream
[16:23] <TJ-> sdeziel: might need to rework the patch to make it look prettier :)
[16:26] <TJ-> sdeziel: although there's only 2 things can be changed; values assigned to the pid_child tell-tale values, and the if (pid_child < NGX_OK || pid_child > NGX_OK) which could be just if (pid_child !=0) or even (pid_child) - although those make the intent of the code obscure
[16:39] <teward> sdeziel: I'd say test Debian and CentOS if you can, I just can't build CentOS packages
[16:39] <teward> Upstream has to support Cent too so I mean :|
[16:41] <teward> this reminds me I *really* need to get my private Debian cloud builders working again
[16:43] <teward> xnox: FYI, 4 of the s390x builders that were building are not stuck in Disabled, the rest are "Idle" so I think that fixed the broken workers problem.
[16:43] <teward> now stuck*
[16:46] <teward> TJ-: well sdeziel seems to suggest the code fixes the headache, do you want to test Eoan and Xenial as well?
[16:46] <teward> Eoan because this lands there first, Xenial because it's LTS too.
[16:46] <teward> and needs this fix heh
[16:46] <TJ-> teward: I don't actually have nginx installed, I just thought I'd hack the patch. It works in a 19.10 container though :)
[16:46] <teward> sarnold: rbasak: if either of you want to review the patch for glaring WTH problems let me know, before I drop this in Eoan, it SEEMS like TJ-'s hacked patch works :P
[16:47] <teward> TJ-: isn't that the point of all patches/hacks?  xD
[16:47] <TJ-> teward: well I like to think I bring some finesse to the job, usually :p
[16:47] <teward> heh
[16:48] <teward> sdeziel: if you can spin an eoan container and make sure it works there that'd be great
[16:48] <teward> this'd land in Eoan first, even if it's just a distropatch
[16:53] <sarnold> teward,TJ-, any changes since last time I looked?
[16:53] <TJ-> sarnold: when did you last look? patch was attached last friday
[16:54] <sarnold> TJ-: sounds about right
[16:54] <sarnold> (well, really, it feels like I just reviewed that yesterday morning.)
[16:54] <teward> lol
[16:55] <teward> sarnold: even if this is a nasty distropatch only I want this race fixed,  We'll let TJ suggest the fix upstream xD
[16:55] <teward> or sdeziel
[16:55] <teward> this race condition is a nasty :p
[16:57] <sdeziel> teward: eoan test successful
[17:01] <sdeziel> sarnold: If I recall the events correctly, you reviewed an old version of TJ's patch. Here's the latest one that tested OK on Bionic/Eoan: https://launchpadlibrarian.net/426320897/nginx-fix-pidfile.8.patch
[17:01] <sarnold> indeed this line is new to me +    child_pid--;
[17:03] <sarnold> alright, it's even more subtle than before, BUT I prefer this patch a thousand times to the systemd-based workarounds that were suggested
[17:03] <sarnold> I wouldn't be surprised if upstream wants to do it differently
[17:03] <TJ-> sarnold: nor me, as they know their code best
[17:03] <sarnold> lets hope :)
[17:03] <TJ-> they have to do something similar though to pull writing of the PID file into the parent process
[17:05] <teward> regardless, if upstream fixes the issue, we can drop the distropatch but I would still want a distropatch that 'works' for older versions of NGINX.  in the short term this is SRUable, if Upstream comes out with a fix we can backport, we can drop this one and replace it with an upstream patch.  :P
[17:07] <TJ-> yeah, and I think I heard someone say nginx-devel is the place to report this rather than trac?
[17:07] <teward> Usually patches get submitted to nginx-devel there's a "Submitting Patches" guide let me grab it
[17:10] <TJ-> I've subscribed so I'll write something later on
[17:11] <teward> fooey I can't find the documentation, so I made a request for them to provide it again :p
[17:11] <teward> and I know Maxim on that list is very good at such things.
[17:11] <teward> sarnold: so, not a horridly nasty patch then?  :P
[17:12]  * TJ- does dinner, bbl
[17:12] <sarnold> teward: exactly
[18:14] <teward> TJ-: looks like there had been patches suggested before for this, and were rejected.  See Maxim's response.  http://mailman.nginx.org/pipermail/nginx-devel/2019-June/012292.html
[18:14] <teward> cc sarnold
[18:14] <teward> looks like Upstream knows this may be an issue and previous patches in the past were rejected
[18:17] <sdeziel> one of the rejected patch was a sleep 0.1 baked in nginx itself :)
[18:17] <sarnold> hah, and here's them pointing out the race in the sleep 0.1 approach :) http://mailman.nginx.org/pipermail/nginx-ru/2017-November/060631.html
[18:17] <sarnold> "sleep 0.1 - это race condition на ровном месте, плохой workaround.
[18:17] <sarnold> along the lines of "this is race condition here, it's a bad workaround
[18:17] <sdeziel> https://mailman.nginx.org/pipermail/nginx-ru/2017-November/060628.html looks better
[18:18] <sarnold> that pipe-based approach is very similar to .. cgmanager? lxd? lxc? iirc something that hallyn worked on; I *really* liked it, but figured that would be a drastic enuogh change that I didn't suggest it
[18:20]  * hallyn perks up
[18:20] <teward> heh
[18:20] <sarnold> hey Hackerpcs :)
[18:20] <sarnold> sigh.
[18:20] <teward> had a feeling that'd happen :P
[18:20] <sarnold> hey hallyn :)
[18:20] <Hackerpcs> yo
[18:20] <hallyn> hey sarnold :)
[18:20] <teward> sarnold: alt-tab with a "Last active" setting on it instead of alphabetical :P
[18:21] <teward> Hackerpcs: sarnold mispinged :P
[18:21] <Hackerpcs> is this from ggn? xD
[18:23] <teward> s/alt-tab/tab-complete/
[18:57] <TJ-> teward: well, of the 2 patches that were rejected, the  100ms sleep is the least invasive, but if upstream won't fix it... no point us submitting my patch!
[18:58] <teward> TJ-: i mean you can try
[18:59] <TJ-> teward: I'm not sure I've the energy to want to push it if they have had two proposed patches, rejected both, and NOT come up with a solution themselves
[18:59] <teward> but yeah i'm probably going to keep this as an added patch/delta
[18:59] <teward> TJ-: i'm not even sure if they consider it an 'issue' TBH
[19:02] <TJ-> teward: I agree, which strikes me as a poor attitude because it plainly is not what is expected behaviour, but they don't seem to publish the systemd unit file - is that originating in Debian or ubuntu?
[19:02] <teward> Debian actually
[19:02] <TJ-> right, so they're adopting the "someone elses problem" attitude
[19:03] <TJ-> I know with my solution there is no race condition, but it'll get objected to for likely being too invasive
[19:08] <teward> indeed.
[19:09] <teward> the tricky part here is, it sounds like this invasiveness is *needed* to make things actually work right...
[19:09] <teward> TJ-: I'm going to let it sit in the PPA for a bit, let sdeziel and others do some more testing
[19:09] <teward> see if this works fine for most production use cases
[19:09] <teward> if it does I'll go the route of uploading for Eoan and getting SRU reviews
[19:12] <sdeziel> TJ-: it would be too bad to admit defeat before sending it upstream but I'd understand you don't want to fight that battle.
[19:13] <sdeziel> TJ-: looking at https://launchpadlibrarian.net/426320897/nginx-fix-pidfile.8.patch, I noticed the 'if (ngx_create_pidfile(&ccf->pid, cycle->log) != NGX_OK) {' line has 1 too many space indent, same for the one after

[20:29] <sdeziel> my netplan setup fails to set the MTU properly, anyone knows about this?
[20:31] <sdeziel> here is the yaml config: https://paste.ubuntu.com/p/zkSV8jrkRk/
[20:32] <sdeziel> once 'netplan apply' is done, the MTU is left at 1500 requiring me to do 'ip link set enp1s0f0 mtu 9000'
[20:37] <sarnold> sdeziel: do you need to set that on the bridge instead?
[20:38] <sdeziel> sarnold: shouldn't be needed because the bridge always adapt to lowest MTU of the enslaved ports. That said, I tried it anyway and it doesn't work ;)
[20:39] <sarnold> sdeziel: dang and double-dang. but thanks for reporting back :)
[20:39] <sdeziel> I also tried setting the MTU on both but no dice, thanks for suggesting
[20:40] <sdeziel> I think the issue is the NIC seems to go down/up on MTU changes
[20:41] <cyphermox> sdeziel: AWS?
[20:41]  * sdeziel misses ifupdown post-up scripts for quick and dirty fixes
[20:42] <sdeziel> cyphermox: no, iron @Home
[20:42] <cyphermox> ok, let me rephrase then, it's DHCP?
[20:42] <sdeziel> cyphermox: no, all static
[20:42] <cyphermox> oh you did paste config
[20:43] <cyphermox> to get the MTU to apply you must match: by MAC or something else that is specific enough to apply to the interface
[20:43] <sdeziel> oh, that would make a fantastic addition to https://netplan.io/examples ;)
[20:44] <sdeziel> cyphermox: my bad, it's already there in https://netplan.io/reference
[20:44] <sdeziel> testing this now, thanks!
[20:44] <cyphermox> well, I guess it's worth having in examples
[20:45] <sdeziel> It would be a good addition IMHO as tuning the MTU is probably something many folks are looking for
[20:50] <sdeziel> cyphermox: it worked, thank you very much!