ignore signal urgent I/O condition logs

[tooptoop4]

when enabling debug level on controller, my workflow UI logs have a lot of below:

time="2024-06-21T07:38:02 UTC" level=debug msg="ignore signal urgent I/O condition" argo=true
time="2024-06-21T07:38:02 UTC" level=debug msg="ignore signal urgent I/O condition" argo=true
time="2024-06-21T07:38:04 UTC" level=debug msg="ignore signal urgent I/O condition" argo=true
time="2024-06-21T07:38:22 UTC" level=debug msg="ignore signal urgent I/O condition" argo=true
time="2024-06-21T07:38:24 UTC" level=debug msg="ignore signal urgent I/O condition" argo=true
time="2024-06-21T07:38:27 UTC" level=debug msg="ignore signal urgent I/O condition" argo=true
time="2024-06-21T07:38:30 UTC" level=debug msg="ignore signal urgent I/O condition" argo=true
time="2024-06-21T07:38:30 UTC" level=debug msg="ignore signal urgent I/O condition" argo=true
time="2024-06-21T07:38:46 UTC" level=debug msg="ignore signal urgent I/O condition" argo=true

anything to be concerned with?
the workflows themself appear to run ok

[agilgur5]

when enabling debug level on controller, my workflow UI logs

Do you mean the logs of each of your steps? As in, the logs of the Executor?
The way you wrote this is quite ambiguous, as "UI logs" would mean browser logs, and seeing the logs of a step Pod would not require the UI either (the Server uses the equivalent of kubectl logs).

The Executor does by default inherit the log configuration of the Controller.

anything to be concerned with?
the workflows themself appear to run ok

Otherwise, this should normally be fine and expected; no concerns.
Go itself uses SIGURG for goroutine preemption since Go 1.14, as #10141 states (can search "SIGURG" in the codebase and blame back to it). This signal normally should not affect the user subprocess.

There is an upstream issue about ignoring own SIGURGs in golang/go#37942, but that wasn't possible with Linux signals per the early comments.

[agilgur5]

Yes, those are the logs of a step Pod; can get the same logs from kubectl logs on your step Pod.

Specifically they are from the Emissary Executor that runs as a parent process to the entrypoint of your container.

[tooptoop4]

could the code filter these out?

[agilgur5]

It's a debug log already so is not shown by default. Per the upstream issue, there's no way of telling if it's a signal not from the Go runtime.

[tooptoop4]

i mean in the javascript side, similar to how it has input text field to only include certain log lines

[agilgur5]

We don't have any automatic filters applied, and I would suggest against them too -- Argo's interface is very close to k8s, which a lot of users, like me, appreciate. The logging interface is raw unless you add a filter, matching kubectl logs exactly

Also auto-filters would need to be implemented in the CLI too.

In this case, it also could be a relevant signal depending on what you're doing, we just have no idea, hence ignored but debug logged just in case.