#general
- b
bored-art-40741
03/23/2016, 7:46 PMBecause there's a correct solution available and trivial to land - b
bored-art-40741
03/23/2016, 7:47 PMIt's preferable to the slightly more output-friendly but incorrect solution - r
rough-minister-58256
03/23/2016, 7:47 PMthat will just get changed next week tho, so we now have 2x overhauls to prove - w
witty-crayon-22786
03/23/2016, 7:47 PMer, it sounds like you all agree about landing 3598 - r
rough-minister-58256
03/23/2016, 7:47 PMmaybe not a huge deal tho - b
bored-art-40741
03/23/2016, 7:47 PMNo - b
bored-art-40741
03/23/2016, 7:48 PM3598 uses
, which can leak stale locksOwnerPrintingPIDLockFile - b
bored-art-40741
03/23/2016, 7:48 PMEric said he had already written up using fasteners for just the ivy lock though - b
bored-art-40741
03/23/2016, 7:48 PMIf that's the case, that's the solution I would prefer to see land - a
ancient-stone-50795
03/23/2016, 7:48 PMSo let's just recap your position: 1) Leaking stale locks is too important of an issue to land the patch 2) Leaking stale locks is OK for the global pants lock - r
rough-minister-58256
03/23/2016, 7:49 PMheh - b
bored-art-40741
03/23/2016, 7:49 PMI didn't say (2) was okay, but since the issue here is around a new lock that's misbehaving, I'm saying the simplest immediate solution in the absence of someone willing to do the full overhaul before Friday is to fix (1) with the lock that's actually misbehaving - a
ancient-stone-50795
03/23/2016, 7:51 PMWhy would the ivy lock misbehave more than the global lock? We will be changing the failure mode to one where just like now, when the lock is stuck we get no useful information. - b
bored-art-40741
03/23/2016, 7:51 PMBecause the global lock is per-checkout - b
bored-art-40741
03/23/2016, 7:51 PMWhereas the ivy lock is truly global to every pants process on the machine - b
bored-art-40741
03/23/2016, 7:51 PM(Maybe not in your environment, but certainly in ours) - r
rough-minister-58256
03/23/2016, 7:52 PMkeep in mind this only comes into play when the lock fails to be removed normally AND theres a stale pid thats been rolled over - b
bored-art-40741
03/23/2016, 7:52 PMYes - b
bored-art-40741
03/23/2016, 7:52 PMHappens to us all the time - w
witty-crayon-22786
03/23/2016, 7:53 PMimo, when https://rbcommons.com/s/twitter/r/3598/ is green in CI, it's worth landing it. can open a separate ticket about changing to fasteners - b
bored-art-40741
03/23/2016, 7:53 PMIf it happens to a single checkout, it's not a big deal - b
bored-art-40741
03/23/2016, 7:53 PMIf it happens to all of ivy resolution for a machine, it's a much bigger deal - b
bored-art-40741
03/23/2016, 7:53 PM@witty-crayon-22786: I disagree - b
bored-art-40741
03/23/2016, 7:53 PMI'd rather see a straight up revert than land another leaky lock - b
bored-art-40741
03/23/2016, 7:53 PMAt least unsafe ivy resolution manifests as an immediate failure and not a deadlock - b
bored-art-40741
03/23/2016, 7:54 PMBut then, there's a three line fix (that it sounds like has already been written) that for some reason is unpopular because it doesn't output enough - b
bored-art-40741
03/23/2016, 7:54 PMJust print "acquiring lock ... lock acquired" in the lock block - a
ancient-stone-50795
03/23/2016, 7:55 PM@bored-art-40741: Have you been seeing the stuck ivy resolve problem in this environment? I assume you mean jenkins? Or are you talking about your internal CI? - a
ancient-stone-50795
03/23/2016, 7:55 PMI don't know if you re-use this part of the code in your internal stuff - a
ancient-stone-50795
03/23/2016, 7:56 PMFor me, the debugging / troubleshooting experience I would like to preserve is showing which process is currently holding the lock