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: tedu@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
> > deraadt@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.
No comments:
Post a Comment