Re: setrlimit hangs the process

[Rich Felker <dalias@libc.org>]

On Thu, Oct 04, 2018 at 11:53:02AM -0400, Rich Felker wrote:
> On Thu, Oct 04, 2018 at 05:41:52PM +0200, Rabbitstack wrote:
> > Please use the following link to download strace since  daemon is refusing
> > to deliver the mail.
> > 
> > https://www.dropbox.com/s/syhbzxvijf7s4v1/agent.strace?dl=0
> 
> Here is the bug:
> 
> 6208  rt_sigprocmask(SIG_SETMASK, ~[HUP INT QUIT ILL TRAP ABRT BUS FPE SEGV TERM STKFLT CHLD PROF SYS RTMIN RT_1],  <unfinished ...>
> 
> Apparently Go has its own version of sigfillset, rather than calling
> the libc one, and it's hard-coded the glibc values for which signals
> are reserved for the implementation (just RTMIN and RT_1) rather than
> honoring SIGRTMIN (which resolves at runtime via a function call),
> which would exempt RT_2 from being blocked too.
> 
> It needs to be fixed on the Go side. I'll look at it later if nobody
> else more familiar with Go gets to it sooner.

If these are the right source files:

https://golang.org/src/runtime/os_linux_generic.go#L33
https://golang.org/src/runtime/sys_linux_amd64.s#L290

Then they're not even making any attempt to avoid stomping on
implementation-internal signals, and there's nothing musl could do to
prevent this. This suggests to me that something in your codebase is
explicitly avoiding RTMIN and RT_1 (33 and 34). Making it also avoid
RT_2 (35) would be a short-term hack you could use to get past this
problem, but there's no guarantee assignments won't change in the
future (this is why SIGRTMIN and SIGRTMAX macros expand to functions
calls). Really if a Go program wants to use libc, it needs to avoid
bypassing libc in ways that change the process state (like signal mask
or disposition).

Rich