NovFora Dev

help with this thing?

Quinn Martin

Quinn Martin

4 months ago

hi im so sorry to bother everyone but i dont understand how to make a basic button work in html -- does anyone know what <button onclick> actually means and where do i put it for a simple submit form, everything keeps breaking when i try -- please help :(

Avery Rodriguez

Avery Rodriguez

3 months ago

dude just run grep through your own logs it's literally 4 lines of stdout and you can see exactly where it exited with 127 which means a missing dependency -- i mean obviously check if you actually installed the sdk before running the build but anyway go google the error code itself instead

Lillian Young

Lillian Young

3 months ago

The issue you're describing is almost certainly not what it appears to be at first glance, which is a common pattern in systems debugging where the observer effect of looking at the problem introduces confounding variables that mask the actual root cause — though I should note as an aside that this isn't always true and there are cases where the act of measurement itself can trigger race conditions by altering timing windows down to the nanosecond level, which is a known issue in low-latency networking stacks.

Let me walk through what I think is happening step by step because if we skip any of these layers we risk missing something important. First, you're reporting that the process exits with code 137, which maps directly to SIGKILL (9), meaning some external entity sent a kill signal rather than the application terminating on its own. The most common sources for this are: OOM killer in Linux, where the kernel terminates processes exceeding memory limits; a container orchestrator like Kubernetes sending a termination signal when a liveness probe fails repeatedly; or an explicit kill -9 from another process.

Second, we need to confirm whether this is actually SIGKILL by checking /var/log/syslog, /var/log/kern.log, or using the dmesg | grep oom-killer command — if you see 'oom-kill' anywhere in those logs, then your process exceeded its memory bounds and was terminated by the kernel to prevent a system freeze. The important thing here is that SIGKILL cannot be caught, blocked, or handled by the application code, so any try/finally blocks you have for cleanup won't execute — which explains why temporary files might not be getting deleted.

Third, if it's not OOM killer, we should look at your liveness probes and deployment configuration to see whether a health check is failing prematurely and triggering a restart loop. A common mistake is setting the initialDelaySeconds too low, so the

Join the conversation to leave a reply.

Sign in to reply

Related topics