Closed gmitrev closed 6 years ago
As commented (but not quickly enough!) on #92...
I would suggest that changing the signal used to trigger the dump would be the best option: https://github.com/treasure-data/serverengine/blob/678bb269ab13e62277d28981b0c7047b146e72dd/lib/serverengine/signals.rb#L29
Perhaps SIGUSR1
?
I don't know context but I guess changing this is only an issue if this forms part of a published API and if we have users that expect SIGCONT
to trigger a coredump.
@robinbowes I didn't want to change the behaviour for existing users hence this PR. A change of the signal is an official API change and would be more appropriate for a larger release.
Oops. CI on Windows is failing.
@tagomoris Any idea how to debug this? I see that the the log is incomplete and the runtime of each test is 1hr which probably means it timed out. Previous builds took around a minute. Is there a way to retrigger the build?
@repeatedly @tagomoris The CI is passing, although it's quite erratic and tests sometimes fail because of random system slowdowns. Do you need me to do anything else to move this forward?
I see. Code itself looks good.
@tagomoris how about this?
LGTM. Unstable CI is another problem anyway... @gmitrev Nice patch!
Hey guys, can we merge this?
Oh, I missed to do it. @mitio Thank you!
As reported in https://github.com/treasure-data/serverengine/issues/92, the
Sigdump.dump
command on receiving aSIGCONT
causes lots of unwanted files in systems wheresystemd
is used to control services that useserverengine
.This PR adds a new setting called
disable_sigdump
that can be used to disable this behaviour. It isfalse
by default since we don't want to break anything for current users.