Containers and workers

portop names the container behind a port and tells a server's master process from its workers.

Docker and Podman

On Linux the container ID comes from the process's cgroup and the name from the Engine API. The socket is found the way the docker CLI finds it: a unix:// DOCKER_HOST, /var/run/docker.sock, rootless Docker in $XDG_RUNTIME_DIR, Docker Desktop's ~/.docker/run/docker.sock, then Podman's /run/podman/podman.sock and its rootless socket.

Kubernetes

On a node running containerd or CRI-O, a pod's process is shown as namespace/pod/container. The names come from the kubelet's log links in /var/log/containers, so no API access or crictl is needed; run portop on the node, usually with sudo.

Docker Desktop on macOS and Windows

Containers run inside a VM, so their processes are not visible to the host. portop recognises them by the host ports Docker publishes, which labels the listening rows.

Masters and workers

Pre-forking servers such as nginx, gunicorn, php-fpm and Apache share one listening socket between a master and its workers. portop shows one row owned by the master, the process whose parent does not hold the socket, and counts the others: nginx +3. The details list the workers' PIDs and JSON has a workers array. With socket activation, systemd (PID 1) also holds the socket and is skipped in favour of the service. On Windows a socket has a single owner.