On Mon, Aug 14, 2023 at 12:02 PM Chandrasekhar R <craman2...@gmail.com> wrote: > > My understanding currently is sudo sets up a signal handler in pre_exec and > another signal handler later on which is tied into its main event loop. > Go gets initialized when the pre_exec signal handler is used and it adds > rt_sigaction(SIGCHLD..) with the SA_ONSTACK flag as mentioned here. > Then after the sudo command (echo) gets executed, the SIGCHLD is received by > one of the go threads which then runs the pre_exec signal handler which is > the old and nonexistent signal handler. > > My approach is to block the Go threads from receiving the SIGCHLD signal and > thus not let the signal to be handled by the old signal handler.
I don't quite understand the scenario you are describing. What matters is the signal handler. When Go adds the SA_ONSTACK flag, it doesn't change the signal handler. Which thread a signal is delivered to does not affect which signal handler gets run. Ian > On Friday, August 11, 2023 at 10:05:48 PM UTC-7 Ian Lance Taylor wrote: >> >> On Fri, Aug 11, 2023 at 11:51 AM Chandrasekhar R <crama...@gmail.com> wrote: >> > >> > I am planning on using a pam module written in Go (specifically >> > https://github.com/uber/pam-ussh) . When I run a script which calls sudo >> > continuously with an echo command, I am noticing zombie/defunct processes >> > starting to pop up. >> > >> > On doing strace, I noticed that the SIGCHLD gets delivered to one of the >> > threads created when Go gets initialized (i.e. the shared object gets >> > loaded). >> > >> > I tried to add one level of indirection by having a separate C code which >> > creates a new thread, sets the signal mask to block SIGCHLD and then use >> > dlopen to open the shared object created using cgo. I am still facing the >> > same issue, is there any pointer on how to fix this issue? I think this >> > would be a wide issue across all PAM modules written using cgo. >> >> As far as I know the specific thread that receives a SIGCHLD signal is >> fairly random. What matters is not the thread that receives the >> signal, but the signal handler that is installed. Signal handlers are >> process-wide. What signal handler is running when you get a SIGCHLD? >> What signal handler do you expect to run? >> >> Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7b395394-da12-4b19-9e07-5c8f7e91dcabn%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWhtpjyXALJoMFVjVWkfA4kntsxjKbK-LJxoSzJ9z%2BLAw%40mail.gmail.com.
