[00:32:06] *** pringlescan has joined #project-FiFo
[00:39:41] *** pringlescan has quit IRC
[01:03:02] <trentster> Licenser: thanks for fixing the chrome/websockets bug :-D confirmed working great!
[01:09:52] *** jim80net has quit IRC
[04:48:05] <Licenser> arekinath back now :) I'm a total idiot when it comes to C, sorry, let me see if I can get some more info out of it ;)
[04:48:08] <Licenser> trentster yay!
[05:10:22] <trentster> Licenser: are you now back in the swing of things and shrugged off the remaining jetlag?
[05:10:55] <Licenser> given I'm awake at 4:45 not entirely ;)
[05:13:56] <trentster> Drink a redbull and get on with the day!;-)
[05:33:35] <arekinath> Licenser: hmm.. what an interesting stack you have there
[05:34:06] <arekinath> Licenser: is it still running?
[05:34:41] <arekinath> Licenser: or, perhaps more relevantly, is pid 19987 running?
[05:44:38] <Licenser> not any more now
[05:44:42] <Licenser> but I can reproduce that
[05:44:56] <Licenser> right now it gets stuck (Even the old code) every time I'm kind of worried that a cleanup failed
[05:56:17] <arekinath> hm
[05:56:19] <arekinath> that's interesting
[05:56:44] <arekinath> all the doors should close and disappear when the process dies
[05:56:52] <arekinath> irrespective of whether it died cleanly or not
[06:00:36] <Licenser> hmm I think I found why ;) I remove the debugs
[06:07:54] <arekinath> Licenser: which debugs?
[06:08:11] <Licenser> I put in debug messages in the zdoor.erl that sayd where exactly it was ;)
[06:08:23] <Licenser> removed the io:formats when I switched from my fork to your version
[06:08:52] <arekinath> oh, right
[06:11:46] <arekinath> that one still running?
[06:12:27] <arekinath> Licenser: what's pid 22263 doing?
[06:13:29] <Licenser> that's the beam.smp for chunter
[06:14:33] <arekinath> so it's managed to waitpid() on itself?
[06:14:52] <arekinath> is there another beam.smp for chunter?
[06:15:06] <arekinath> what pid is that mdb trace coming from?
[06:15:19] <arekinath> 22226, right, from the top
[06:15:35] <arekinath> can you get a stack from 22263?
[06:15:57] <Licenser> sure
[06:16:09] <Licenser> pstack: cannot examine 22263: no such process or core file
[06:16:40] <arekinath> hm
[06:17:16] <arekinath> so, the thing is... zdoor_fattach actually forks off a child that enters the zone to go attach the far end of the door
[06:17:59] <arekinath> that stack you got shows the main chunter's zdoor worker thread blocked in waitpid(), waiting on that child process doing the attachment to finish
[06:18:23] <Licenser> hmmm
[06:18:30] <Licenser> could it be related to a zone not beeing booted?
[06:18:42] <arekinath> maybe. maybe the beam has done some funny business with its child, too...
[06:19:32] <Licenser> how do you see that it is in whatpid? I don't even find that string in the trace
[06:20:41] <Licenser> oh wait not what :)
[06:21:08] <Licenser> so out of curiosity, shouldn't that be in a thread and not block the beam?
[06:24:50] <arekinath> it is in a thread... but the jobthread keeps holding the lock after it starts a job
[06:24:58] <arekinath> so the next time you try to add a job you can't get the lock
[06:25:04] <arekinath> because the job thing is blocked
[06:25:07] <arekinath> should probably fix that
[06:25:27] <Licenser> ah makes sense
[06:30:26] <arekinath> but there's still the problem of why the job thread is stalled in waitpid...
[06:31:27] <Licenser> updating and retrying
[06:31:32] <Licenser> lets find out :)
[06:32:23] <Licenser> nope still the same
[06:33:21] <arekinath> that process should still sit in receive forever but the beam shouldn't block up...
[06:33:23] <arekinath> hmm
[06:35:22] <Licenser> I can get the the shell with ^G but that's likely because at that point the shell lands on a different scheduler
[06:35:39] <arekinath> and this is happening just by starting it up and opening a door?
[06:35:53] <Licenser> yup
[06:37:27] <arekinath> I'll see if I can repro it here
[06:37:32] <arekinath> it seems to work though. did you say you have stopped zones?
[06:38:21] <Licenser> yup
[06:40:26] <arekinath> that doesn't seem to be it... at least not with only one zone
[06:40:55] <Licenser> but I can also have the same effect it
[06:41:26] <Licenser> removed the stopped VM
[06:48:40] <arekinath> could it be opening the same door twice?
[06:50:48] <arekinath> anyway, if it's still blocking the whole BEAM, is the stack trace the same?
[06:54:19] <Licenser> yup still waiting for the waitpid
[07:21:19] *** MerlinDMC has quit IRC
[07:22:55] *** MerlinDMC has joined #project-FiFo
[10:08:14] *** wiedi has joined #project-FiFo
[11:46:46] *** ira has joined #project-FiFo
[13:21:30] *** tomww has quit IRC
[14:01:28] *** tomww has joined #project-FiFo
[14:45:36] *** mgls has joined #project-FiFo
[15:16:51] *** jim80net has joined #project-FiFo
[16:30:22] *** pringlescan has joined #project-FiFo
[16:33:30] <pringlescan> Hm… I wonder if an EdgeMax router could handle running HAProxy on it
[16:54:22] *** pringlescan has quit IRC
[17:02:45] *** pringlescan has joined #project-FiFo
[17:37:18] <pringlescan> I finally got FIFO working in my datacenter, but now I get a "Your cloud needs attention" with a "Chunter server 1884530f-6d41-484b-adaf-4bee3b0a2a0f down."
[17:39:02] <pringlescan> Licenser: This command lets a node join an existing ring, please note that order is important all existing data on the joining node will be deleted and only the data on the joined node will persist! — does this mean configuration data for fifo?
[17:40:22] <badboy_> heho guys.
[17:42:21] <badboy_> How is the vnc implemented in project fifo?
[17:54:26] *** badboy_ has quit IRC
[18:09:25] *** badboy_ has joined #project-FiFo
[19:14:38] <badboy_> Ok, great.
[19:15:57] *** pringlescan has quit IRC
[19:46:11] *** pringlescan has joined #project-FiFo
[21:07:43] *** pringlescan has quit IRC
[22:05:28] *** pringlescan has joined #project-FiFo
[22:10:08] *** pringlescan has quit IRC
[22:11:28] *** pringlescan has joined #project-FiFo
[22:12:10] *** pringlescan has quit IRC
[23:09:51] *** jim80net has quit IRC
[23:10:01] *** mgls has quit IRC