openlang

Does Go reserve SIGUSR1 and SIGUSR2?

Dear programmers,

we want to execute a go application under dmtcp (GitHub hosts dmtcp/dmtcp, the DMTCP distributed multithreaded checkpointing project (https://github.com/dmtcp/dmtcp)). The checkpointing tool relies on SIGUSR2 (alternatively SIGUSR1) and objects when an application it manages also uses these. Our tests appear to show that all go applications, including trivial ones, use each of those signals. I looked through the documentation without finding this, apologies if I overlooked the relevant bit. Are you familiar with this behavior, and can go be told not to use either signal?

Thanks very much

The conversation continues 2

Follow the reasoning
  1. Permalink

    Hello!

    Go applications intrinsically rely on SIGUSR1 (profiling) and SIGUSR2 (runtime administration), which clashes with DMTCP's usage of these same signals (DMTCP may alternatively select SIGUSR1). At present, Go's runtime offers no straightforward option to stop using them. Possible approaches involve omitting runtime/pprof imports, carefully setting DMTCP to SIGUSR1 alone, keeping Go processes separate, or asking DMTCP maintainers for tailored guidance. Handling these signals yourself within Go is emphatically not advised alongside DMTCP.

Other sides of the same question

  1. Opening files on Raspberry Pi 4

    On a Raspberry Pi 4 I use fopen inside a for loop to read files from a particular directory, over 1200 of them. Once the loop…

    Replies 2Latest activity c
  2. How can an inets server be stopped?

    Hello, I've got a fairly elementary question about inets (which, incidentally, I find quite handy because it needs no additio…

    Replies 2Latest activity erlang