On 17-07-28 23:34:29, viq wrote: > On 17-07-28 16:04:16, Ted Unangst wrote: > > moving to ports > > > > viq wrote: > > > On 17-07-27 10:35:08, Ted Unangst wrote: > > > > CVSROOT: /cvs > > > > Module name: src > > > > Changes by: t...@cvs.openbsd.org 2017/07/27 10:35:08 > > > > > > > > Modified files: > > > > lib/librthread : rthread.c rthread_fork.c > > > > > > > > Log message: > > > > bad things can (and will) happen if a threaded program calls fork() and > > > > then strays off the path to exec(). one common manifestation of this > > > > problem occurs in pthread_join(), so we can add a little check there. > > > > first person to hit this in real life gets to change the error message. > > > > > > So, uh, would that be me? > > > $ doas salt-minion > > > great scott! serious repercussions on future events! > > > $ echo $? > > > 250 > > > $ sysctl kern.version > > > kern.version=OpenBSD 6.1-current (GENERIC) #13: Thu Jul 27 19:51:38 MDT > > > 2017 > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > > > i'm not sure what salt is doing (or even what it is), > > I can't tell you what it's doing, but it's a remote execution and > configuration management framework written in python, running (by > default) over ZeroMQ. > > > but this is probably not > > good. calling pthread_join() in the child after fork() is not something > > you're > > supposed to do. > > > > anybody know what's going on? > > From my running salt with trace logs, it seems that salt initialises > everything, opens it's IPC sockets, initiates it's AES auth/handshake > with master, and that's when things die.
Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines, 4.2MB compressed
