Learn › Mental Models › Everything is a Queue
ss -ltn - a hands-on Linux lab on a real virtual machine.
The queue model in its second subsystem: find a socket's accept queue with ss, fill it to its backlog, watch the kernel silently ignore the overflow, then wake the server and drain the line. Same shape as the run queue, new costume.
Work order 4472: a service on this machine is listening, but clients say nothing ever answers. You know this shape from the run queue lab, except the servers there were CPU cores. Here the server is a program that accepts connections, and it is asleep at the window while the line grows.
Same model, new costume: arrivals are connections, the line is the socket's accept queue, and the capacity is its backlog. By the end you will have filled a real accept queue to its limit, watched the kernel turn away the overflow, and drained the whole line by waking the server up.
Your progress is tracked automatically. Just type commands naturally. Two helper commands are installed for this scenario: send-customers N (opens N client connections and holds them) and open-registers (tells the sleeping service to start serving).
Press Tab to complete commands and paths. Press the Up arrow to repeat your last command; you will want it for watching the line change.
List the listening sockets and find the ticket window's line.
ss -ltnYou will see:
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 5 127.0.0.1:7000 0.0.0.0:*
LISTEN 0 128 [::]:22 [::]:*Remember from the Everything is a Queue lesson: for a listening socket, Recv-Q is the line length right now and Send-Q is the longest line it will tolerate (the backlog). The ticket window on port 7000 has an empty line and room for 5. The SSH server next to it tolerates 128. Capacity is a design decision, and now you can read it.
Send 3 customers to the window and confirm the line is 3 deep.
send-customers 3You will see:
Sending 3 customer(s) to the ticket window (127.0.0.1:7000)...
The line right now (Recv-Q on :7000): 3
Look closer any time: ss -ltnThree connections completed their handshake and now stand in the accept queue, waiting for a program that never calls accept. They will stand there forever. This is the socket version of processes waiting in the run queue, except nothing is draining it at all.
Send 10 more customers and read what the line ACTUALLY holds.
send-customers 10Then look closely:
ss -ltnYou will see something like:
LISTEN 6 5 127.0.0.1:7000 0.0.0.0:*Thirteen customers sent in total, and the line holds 6. The backlog said 5; the kernel seats one extra, then simply stops answering the door. The other seven arrivals are not queued, not refused with an error, just left waiting outside until they give up. That silent ignoring is exactly what a SYN flood weaponizes, and exactly why "my connections hang sometimes" is a queue symptom, not a network gremlin.
Notice what the overflow did NOT do: it did not grow the line past its cap, and it did not crash anything. Full queues fail quietly. The only way to see this failure is to read Recv-Q against Send-Q, which you now do.
Wake the service so it starts serving the line.
open-registersYou will see:
Registers are OPEN. The window is serving the line.
Watch it drain: ss -ltnConfirm the line has drained to zero while the window is still open.
ss -ltnYou will see the 7000 line back at Recv-Q 0. The service accepts each waiting connection the moment it can, the queue empties in a blink, and every future arrival gets served immediately. Arrivals stopped exceeding service: the line vanished. Third time you have watched that law, second subsystem.
Two subsystems, one shape. That second column is what the transfer research calls a schema forming: next time you meet a full queue (a disk, a lock, a Kubernetes scheduler) you will not be meeting a stranger.
Practice Lab: Read the Accept Queue in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.