/srv/irclogs.ubuntu.com/2019/06/04/#ubuntu-server.txt

geniisarnold: I think he has some idea that because now he knows how to install thing in linux his career will be to be a sysadmin03:34
sarnoldgenii: aye.. it's perhaps a longer road than he suspects, but still, I want to help folks as I can :)03:34
geniiHehe, helluva long road03:35
sarnoldyeah :)03:45
lordievaderGood morning06:12
jamespagecoreycb: I've uploaded SRU's for bionic, cosmic and disco for the neutron internal dns fixes10:16
=== cpaelzer__ is now known as cpaelzer
coreycbjamespage: thanks12:01
=== BlackDex_ is now known as BlackDex
coreycbsahid: I've merged/uploaded everything except neutron so far for bug 183069513:39
ubottubug 1830695 in nova (Ubuntu Cosmic) "[SRU] rocky stable releases" [High,Triaged] https://launchpad.net/bugs/183069513:39
coreycbjamespage: fyi ^13:39
supamanabout 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:13
sdezielsupaman: Xenial only ships with PHP 7.0 packages so those are all build against this version14:26
supamansdeziel: even cakephp?14:31
supamanhttps://packages.ubuntu.com/xenial/web/cakephp14:32
=== cpaelzer__ is now known as cpaelzer
sdezielsupaman: yes14:34
TJ-sdeziel: teward I'll leave Bug #1581864 up to you to respond14:37
ubottubug 1581864 in nginx (Ubuntu Eoan) "nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument" [Low,Confirmed] https://launchpad.net/bugs/158186414:37
sdezielteward: do you plan to provide another PPA with the TJ's new patch? If yes I would give it a test run14:43
tewardsdeziel: TJ-: yes, but right now i'm fixing a major network bug at work14:47
tewardi'll upload with p1 attached to the version string I had uploaded previously so it bumps up14:47
tewardgive me a minute i have to fix this crap14:47
sdezielthank you both14:47
tewardahasenack: RE: your comment about intrusive patches14:49
tewardi think Upstream would want evidence it works before including14:49
ahasenacksure14:49
tewardwe can test-drive it in a PPA first14:49
tewardif it works there then we can SRU it here and next NGINX release with it in it I can upload it to Eoan14:49
ahasenackI checked fedora, the same thing happens there, fwiw14:49
tewardand drop the delta14:49
tewardahasenack: yeah it's an upstream issue, TJ ID'd it in the code14:50
tewardgrrr this darn network bug...14:50
ahasenackwas an upstream bug even filed?14:50
tewardwonder if a switch is broken... BRB14:50
tewardahasenack: I didn't see one, but we could always search Trac14:50
ahasenackugh, trac14:50
tewardmost things don't end up in the Trac tracker and just on nginx-devel@14:50
sdezielTrac is a good deterrent for bug reporters ;)14:54
ahasenackdidn't want to say it, but there it is :)14:56
TJ-ahasenack: I didn't want to report a bug until we're sure we're aiming at the correct target!15:20
ahasenackTJ-: fair :)15:24
tewardTJ-: PM me yoru email address to use on the DEP3 headers?15:39
teward'cause i'm adding headers xD15:39
TJ-teward: same as last time; ubuntu@iam.tj or hacker@iam.tj15:39
tewardyeah but i lost my logs :P15:40
tewardthanks15:40
TJ-:p15:40
TJ-didn't keep the patch? tut tut :D15:40
tewardlost the headers in my logs15:40
tewardTJ-: 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
tewardp1 appended to version strings15:49
tewardbuilding: Xenial, Bionic, Cosmic, Disco, Eoan.15:50
tewardTJ-: 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 :P16:07
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 exits16:08
teward*nods*16:09
TJ-just lucky on SMP the forked child gets going and creates that before parent exits on the other thread16:09
tewardlooks like s390x is the only arch in the PPAs that's backlogged and the rest were built.16:09
tewardright16:09
xnoxteward:  odd, asking to clean them.16:10
tewardxnox: heh, didn't know you were tracking xD16:10
tewardxnox: ahhh i think that's because many are stuck in a cleaning loop and a few are disabled16:11
tewardof the 20 s390x builders, 5 are disabled 4 are doing builds and the rest stuck on cleaning16:11
xnoxteward:  tracking what? =)16:11
tewardxnox: when people complain about PPA buidlers being weird :P16:12
sdezielteward: TJ-: test successful on bionic16:22
sdeziellet me know if you want some other distro tested prior to proposing upstream16:23
TJ-sdeziel: might need to rework the patch to make it look prettier :)16:23
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 obscure16:26
tewardsdeziel: I'd say test Debian and CentOS if you can, I just can't build CentOS packages16:39
tewardUpstream has to support Cent too so I mean :|16:39
tewardthis reminds me I *really* need to get my private Debian cloud builders working again16:41
tewardxnox: 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
tewardnow stuck*16:43
tewardTJ-: well sdeziel seems to suggest the code fixes the headache, do you want to test Eoan and Xenial as well?16:46
tewardEoan because this lands there first, Xenial because it's LTS too.16:46
tewardand needs this fix heh16: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
tewardsarnold: 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 :P16:46
tewardTJ-: isn't that the point of all patches/hacks?  xD16:47
TJ-teward: well I like to think I bring some finesse to the job, usually :p16:47
tewardheh16:47
tewardsdeziel: if you can spin an eoan container and make sure it works there that'd be great16:48
tewardthis'd land in Eoan first, even if it's just a distropatch16:48
sarnoldteward,TJ-, any changes since last time I looked?16:53
TJ-sarnold: when did you last look? patch was attached last friday16:53
sarnoldTJ-: sounds about right16:54
sarnold(well, really, it feels like I just reviewed that yesterday morning.)16:54
tewardlol16:54
tewardsarnold: even if this is a nasty distropatch only I want this race fixed,  We'll let TJ suggest the fix upstream xD16:55
tewardor sdeziel16:55
tewardthis race condition is a nasty :p16:55
sdezielteward: eoan test successful16:57
sdezielsarnold: 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.patch17:01
sarnoldindeed this line is new to me +    child_pid--;17:01
sarnoldalright, it's even more subtle than before, BUT I prefer this patch a thousand times to the systemd-based workarounds that were suggested17:03
sarnoldI wouldn't be surprised if upstream wants to do it differently17:03
TJ-sarnold: nor me, as they know their code best17:03
sarnoldlets hope :)17:03
TJ-they have to do something similar though to pull writing of the PID file into the parent process17:03
tewardregardless, 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.  :P17:05
TJ-yeah, and I think I heard someone say nginx-devel is the place to report this rather than trac?17:07
tewardUsually patches get submitted to nginx-devel there's a "Submitting Patches" guide let me grab it17:07
TJ-I've subscribed so I'll write something later on17:10
tewardfooey I can't find the documentation, so I made a request for them to provide it again :p17:11
tewardand I know Maxim on that list is very good at such things.17:11
tewardsarnold: so, not a horridly nasty patch then?  :P17:11
* TJ- does dinner, bbl17:12
sarnoldteward: exactly17:12
tewardTJ-: 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.html18:14
tewardcc sarnold18:14
tewardlooks like Upstream knows this may be an issue and previous patches in the past were rejected18:14
sdezielone of the rejected patch was a sleep 0.1 baked in nginx itself :)18:17
sarnoldhah, and here's them pointing out the race in the sleep 0.1 approach :) http://mailman.nginx.org/pipermail/nginx-ru/2017-November/060631.html18:17
sarnold"sleep 0.1 - это race condition на ровном месте, плохой workaround.18:17
sarnoldalong the lines of "this is race condition here, it's a bad workaround18:17
sdezielhttps://mailman.nginx.org/pipermail/nginx-ru/2017-November/060628.html looks better18:17
sarnoldthat 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 it18:18
* hallyn perks up18:20
tewardheh18:20
sarnoldhey Hackerpcs :)18:20
sarnoldsigh.18:20
tewardhad a feeling that'd happen :P18:20
sarnoldhey hallyn :)18:20
Hackerpcsyo18:20
hallynhey sarnold :)18:20
tewardsarnold: alt-tab with a "Last active" setting on it instead of alphabetical :P18:20
tewardHackerpcs: sarnold mispinged :P18:21
Hackerpcsis this from ggn? xD18:21
tewards/alt-tab/tab-complete/18:23
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:57
tewardTJ-: i mean you can try18:58
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 themselves18:59
tewardbut yeah i'm probably going to keep this as an added patch/delta18:59
tewardTJ-: i'm not even sure if they consider it an 'issue' TBH18:59
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
tewardDebian actually19:02
TJ-right, so they're adopting the "someone elses problem" attitude19:02
TJ-I know with my solution there is no race condition, but it'll get objected to for likely being too invasive19:03
tewardindeed.19:08
tewardthe tricky part here is, it sounds like this invasiveness is *needed* to make things actually work right...19:09
tewardTJ-: I'm going to let it sit in the PPA for a bit, let sdeziel and others do some more testing19:09
tewardsee if this works fine for most production use cases19:09
tewardif it does I'll go the route of uploading for Eoan and getting SRU reviews19:09
sdezielTJ-: 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:12
sdezielTJ-: 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 after19:13
sdeziel</nitpicking>19:14
sdezielmy netplan setup fails to set the MTU properly, anyone knows about this?20:29
sdezielhere is the yaml config: https://paste.ubuntu.com/p/zkSV8jrkRk/20:31
sdezielonce 'netplan apply' is done, the MTU is left at 1500 requiring me to do 'ip link set enp1s0f0 mtu 9000'20:32
sarnoldsdeziel: do you need to set that on the bridge instead?20:37
sdezielsarnold: 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:38
sarnoldsdeziel: dang and double-dang. but thanks for reporting back :)20:39
sdezielI also tried setting the MTU on both but no dice, thanks for suggesting20:39
sdezielI think the issue is the NIC seems to go down/up on MTU changes20:40
cyphermoxsdeziel: AWS?20:41
* sdeziel misses ifupdown post-up scripts for quick and dirty fixes20:41
sdezielcyphermox: no, iron @Home20:42
cyphermoxok, let me rephrase then, it's DHCP?20:42
sdezielcyphermox: no, all static20:42
cyphermoxoh you did paste config20:42
cyphermoxto get the MTU to apply you must match: by MAC or something else that is specific enough to apply to the interface20:43
sdezieloh, that would make a fantastic addition to https://netplan.io/examples ;)20:43
sdezielcyphermox: my bad, it's already there in https://netplan.io/reference20:44
sdezieltesting this now, thanks!20:44
cyphermoxwell, I guess it's worth having in examples20:44
sdezielIt would be a good addition IMHO as tuning the MTU is probably something many folks are looking for20:45
sdezielcyphermox: it worked, thank you very much!20:50

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!