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.
