u/AtmosphereRich4021

Today while working on a remote Linux server over SSH, I ran:vim /srv//project/.env

The directory path was incorrect, and vim opened into what looked like a completely frozen black screen. Keyboard input appeared unresponsive, so I closed the terminal assuming the session was dead.After that, I noticed an old SSH session (pts/0) remained alive for hours and the server started behaving strangely.Symptoms included:ps hanging

kill -9 hanging

pkill hanging

some filesystem-related commands blocking indefinitely

attempts to inspect the stuck process also hangingAt first I thought I had triggered a D-state (uninterruptible sleep) process because even SIGKILL appeared ineffective.What made this more confusing:filesystem is local ext4 on /dev/md2

no NFS/network mounts involved

dmesg showed no obvious disk or I/O errors

new SSH sessions still worked, but random commands would intermittently blockLater I realized I had also accidentally triggered terminal flow control (Ctrl+S), which made the terminal appear frozen multiple times and likely made the situation look much worse than it actually was.I’m trying to understand what really happened here:Could a normal vim session realistically enter true D-state from something this simple?

Why would commands like ps or kill appear to hang?

Was this likely a terminal/PTY state issue rather than an actual kernel-level I/O hang?

pllll help

I was assigned to build a minimal docker image for bun backend in a monorepo... I started with the usual setup (node_modules copied into the image, multistage build) and ended up with ~1.2 gb image.

So i switched approach, used bun's --compile to build a single binary.

RUN bun install --filter server
COPY apps/server ./apps/server
WORKDIR /app/apps/server
RUN bun build src/index.ts --compile --minify --outfile server

for base image im using oven/bun & for runtime gcr(dot)io/distroless/base-debian12... now the final image is ~190 mb (binary ~115 mb + base)

we will be deploying he container in gcp cloud run...so is this approch fine ? i didnt find may refs regarding to this binary approach ( rust do this, traditionally i dont see ts binary deployment, most examples i see just copy the node_modules)... so if this fine? any suggestions for further improvement?

I was assign to build a minimal docker image for Bun backend in a monorepo... I started with the usual setup (node_modules copied into the image, multi-stage build) and ended up with ~1.2–1.3GB images.. ref: https://bun.com/docs/guides/ecosystem/docker

So I switched approach entirely used Bun’s --compile to build a single binary. ref : https://bun.com/docs/bundler/executables & https://bun.com/docs/bundler basically i did

RUN bun install --filter server
COPY apps/server ./apps/server
WORKDIR /app/apps/server
RUN bun build src/index.ts --compile --minify --outfile server
# Then copy compiled binary only in my runtime image

for base image using oven/bun:1.3.5 & for runtime gcr.io/distroless/base-debian12 Now the image is ~190MB (binary ~115MB + minimal base).

We will be deploying the container in Cloud Run...so is this approch fine? i didn't fine many refs regarding this binary approch (rust do this, traditionally i dont see ts binary deployment, most examples I see still just copy node_modules.).. Any suggestion for further optimization?