skip setup signal notifier for detached container

[lifubang]

For detached container, we don't need to setup signal notifier, because there is no customer to consume the signals in forward().

[kolyshkin]

Yeah, it's weird. We set up signal forwarding (for create/run/exec) and then we don't use it.

But, if notifySocker is non-nil, we set up signal forwarding and when we do forward signals for some short time (until we exit).

I can't review it because the current code makes no sense to me :(

[lifubang]

But, if notifySocker is non-nil, we set up signal forwarding and when we do forward signals for some short time (until we exit).

I don’t think so, if notifySocket is non-nil, we also don’t consume any signals. There are two places checking detach in ‘forward()’:

1. runc/signals.go

   Lines 73 to 75 in b2d5924

   	if detach && h.notifySocket == nil {
   	return 0, nil
   	}

2. runc/signals.go

   Lines 82 to 86 in b2d5924

   	if h.notifySocket != nil {
   	if detach {
   	_ = h.notifySocket.run(pid1)
   	return 0, nil
   	}

The signal consumer is in:

runc/signals.go

Line 95 in b2d5924

for s := range h.signals {

If I miss something, please tell me.

[kolyshkin]

Ah, yes, you are right, if detach is true, it exits either way. But the code around notifySocket is spaghetti (in a bad way).

[kolyshkin]

LGTM (yet I wish someone can refactor the code dealing with notifySocket, it seems it is orthogonal to signals and yet it is mixed together)

[lifubang]

yet I wish someone can refactor the code dealing with notifySocket, it seems it is orthogonal to signals and yet it is mixed together

Refactored. I think we should setup notify socket first before we handler and forward signals for non detached containers, so I didn't split them to two functions, but refactor to keep one path for detached container.
PTAL