Cleaning up your systemd service
Retiring a service is more than killing the process. Here's the four-beat teardown I ran to remove a honeypot from my box — and why 'disable' isn't 'stop'.
Topic
Running the box: Docker, Linux, the JVM
What actually happens between systemd and your fat jar.
The localhost in your SSH tunnel isn't yours
My production Postgres publishes no port at all, and I still open it in DBeaver from my laptop. The one-line ssh -L everyone reaches for connects happily and then refuses every query — for a reason that's easy to miss, and eight bytes that prove when you've actually fixed it.
Where does app.jar find its dependencies? The JVM rule hiding in your Dockerfile
Spring Boot's layered jar extraction splits your dependencies from your code for faster Docker rebuilds. But the mechanism that makes the pieces find each other at runtime isn't Spring at all — it's a JVM rule from 1998.
Systemctl isn't the thing that runs your services
systemctl doesn't start your services — it's a client that phones PID 1. A mental model of systemd built from the D-Bus call down to the kernel cgroups that make it all reliable.