Short-lived processes complete before eBPF hooks can attach - possible enhancement?

I've been using eCapture v1.4.3 in a production Kubernetes environment to monitor SSL/TLS traffic, and it's working great for long-running services. However, I've noticed that short-lived processes (like
curl, wget, or any script that makes a quick HTTPS call and exits) complete their SSL operations before eCapture's eBPF hooks can attach.

Environment:
- eCapture version: v1.4.3
- Kernel: 6.8.0 (x86_64)
- Libraries detected: OpenSSL 3.0, OpenSSL 1.1.1, GnuTLS 3.x
- Deployment: DaemonSet mode, auto-detecting libraries every 30 seconds

Expected behavior:
Capture SSL/TLS plaintext from all processes, including short-lived ones.

Actual behavior:
- ✅ Long-running processes (web servers, APIs, databases): captured successfully
- ❌ Short-lived processes (curl, wget, one-off scripts): complete before hooks attach

Example scenario:
# This completes in ~500ms, hooks attach too late
curl https://api.example.com/endpoint

# eCapture log shows:
# "Found openssl in PID 12345"
# "Starting eCapture for PID 12345"
# But by then, curl has already finished and exited

My understanding:
I believe this happens because:
1. eCapture scans /proc to find processes with SSL libraries loaded
2. eBPF uprobes are attached to those PIDs
3. But if the process completes the SSL handshake and exits before step 2 finishes, we miss the traffic

Question:
Is there a way to work around this timing issue? Some ideas (not sure if feasible):

1. Could eCapture attach probes globally to the SSL library files (e.g., /usr/lib/libssl.so) instead of per-process, so the hooks are already active when any process loads the library?
2. Could we use a combination of kprobe on execve() + fast uprobe attachment to catch new processes immediately as they start?
3. Is there a tracepoint or alternative hooking mechanism that doesn't have this race condition?

I understand this might be a fundamental limitation of how eBPF uprobes work with process attachment, but I wanted to check if there's a known solution or if this could be a potential enhancement.

Start by reviewing the /proc library scan and per-PID eBPF uprobe attachment described in the issue. Compare the proposed global SSL-library probes, execve hook, and alternative tracepoints, focusing on whether they can attach before a short-lived process performs TLS operations. Done means reliably capturing short-lived processes without losing their traffic to the attachment race.

Written by the indexing model from the issue text.