lima-guestagent: support external trigger via sighup notification #3766
Conversation
Supplement the periodic port update ticker by a signal based trigger mechanism. This allows for more responsive update of the portmapping. External tools can notify the lima-guestagent by means of a SIGHUP. The SIGHUP notification is handled like the periodic update ticker. Signed-off-by: Alain Lehmann <alain.lehmann@gmail.com>
|
Thank you for your PR! There is however a more comprehensive PR in preparation, that will use the events API for containerd, dockerd, and kubernetes, to send immediate port notifications. For various non-technical reasons it has been in progress for a long time, but should be ready for consideration very soon. It is based on the Rancher Desktop guest agent on Windows. You can take a look at the in-progress changes at Nino-K#2 Given that this PR will hopefully land within the next couple of weeks, I think this signal mechanism should not be merged. |
|
Thank you for the quick response. I see that the referenced PR is more tightly integrated (at the cost of more complexity). The openness of the signal based approach might still be interesting, though. But I see that most use cases (including my current one) are probably covered by that other PR. So I'm looking forward to that other PR to land. Thanks again. |
cmd/lima-guestagent/daemon_linux.go
Outdated
| @@ -58,7 +60,43 @@ func daemonAction(cmd *cobra.Command, _ []string) error { | |||
| // without depending on `bpftrace` binary. | |||
| // The agent binary will need CAP_BPF file cap. | |||
| ticker := time.NewTicker(tick) | |||
| return ticker.C, ticker.Stop | |||
|
|
|||
| logrus.Info("register for sighup notifications") | |||
There was a problem hiding this comment.
Nit: probably sighup should be spelled in the upper chars, as it might look like "sigh up" (?) or a typo of sign-up
|
|
||
| logrus.Info("register for sighup notifications") | ||
| sighupC := make(chan os.Signal, 1) | ||
| signal.Notify(sighupC, syscall.SIGHUP) |
There was a problem hiding this comment.
Please add a comment line to explain who sends SIGHUP
There was a problem hiding this comment.
Sure, I have added a comment about the purpose of the SIGHUP mechanism and also improved the log message.
Signed-off-by: Alain Lehmann <alain.lehmann@gmail.com>
The Lima guest agent currently uses a polling strategy to update the ports exposed to the host system. For some use cases (e.g. testcontainers (rancher-sandbox/rancher-desktop#3141)), this may not be responsive enough. This PR supplements the periodic ticker with an optional, push-based trigger based on OS signals. External processes can thus trigger a port update via SIGHUP, enabling a more timely response -- for example, by reacting to docker events.
In my testing, this consistently reduced the time until a port became reachable -- without increasing the polling frequency.
The implementation requires minimal changes to lima-guestagent and is not tied to a specific event source. i.e. it is open to any kind of trigger.
I hope this change is of value to this interesting project. I'm looking forward to your feedback.
Validation Experiment
An example implementation of the trigger might look like:
which can be run in a systemd unit and optionally filter for specific events (e.g. start/stop/kill).
Timing experiment has been done with ciderale/nixos-lima using lima 1.2.0 with test-portmapping.sh, starting 100 alpine/socat containers (each delayed by 0.3s, on different ports) and measuring time till each request has been fulfilled. The results are: