I first thought this would be a problem too, but if you look at the flow of execution, these signals only come into play on the initial start before the process has been daemonized. cli.parse gets called and starts the daemonizing. When it's JRuby we set up these two signals and start a completly new sidekiq daemon process. This daemon process sees that it has already daemonized and finalizes by calling JRubyRestart.perm_daemonize (Killing the old „master“, not setting up any Signals for daemonizing use). 

After that the normal init processing from cli.parse continues and the normal handling of the Signals gets set up.

So while the signal has two uses, it's only for the short span of time before the master has set background process.