`systemctl start myapp.service` returns immediately and `systemctl status` reports active (running), but the application does not accept connections for another twenty seconds. What does "active" actually mean under the default Type=simple, and how do you make systemd wait for real readiness?

## What "active" is a statement about A systemd unit's active state is a statement about the *job* systemd ran, not about the health of your application. `Type=` in the `[Service]` section is precisely the knob that decides when systemd declares the start job complete, and the default is the loosest possible answer. ## Type=simple: forked is started ```ini [Service] ExecStart=/usr/local/bin/exampled --listen :8080 ``` With no `Type=` and an `ExecStart=`, this is `Type=simple`. systemd forks, arranges the child's environment, and immediately reports the unit as `active (running)`. The child may then fail to `execve()` because the path is wrong, or exec fine and spend twenty seconds loading a model into memory, or bind nothing at all — systemd cannot tell the difference, because it never asked. This produces two familiar symptoms. First, a typo in `ExecStart=` shows up as a unit that is active for a few milliseconds and then failed, rather than a start command that returns an error. Second, anything scheduled to follow this unit begins while it is still warming up. ## Type=exec: wait for the exec to succeed `Type=exec` behaves like `simple` except that systemd holds the start job until the child has successfully executed the binary. A missing file, a non-executable bit, or a bad interpreter now fails the start job itself, so `systemctl start` returns non-zero and says so. It still tells you nothing about readiness — exec succeeding is not the application working — but it removes a whole class of confusing "it said it started" reports. `Type=exec` requires systemd 240 or newer. ## Type=notify: the service says when it is ready ```ini [Service] Type=notify NotifyAccess=main ExecStart=/usr/local/bin/exampled TimeoutStartSec=120s ``` Under `Type=notify`, systemd passes a Unix datagram socket to the service through the `NOTIFY_SOCKET` environment variable and waits. The service finishes its own startup — opening its database pool, loading configuration, binding its listener — and then sends a readiness datagram: ```c sd_notify(0, "READY=1"); ``` Only at that point does the unit become `active (running)`. If the message never arrives, the start job hangs until `TimeoutStartSec=` (90 seconds by default) elapses and the unit is marked failed with a timeout. `NotifyAccess=` controls which processes may send the message; `main` is the default and is what you want unless a helper process must do the notifying. A program does not need the C library binding: any process can write to `$NOTIFY_SOCKET`, and shell units can simply run `systemd-notify --ready`. The same channel also carries `STATUS=` strings, which then appear in `systemctl status` output, and `RELOADING=1` for reload progress. ## The other types you will be asked to distinguish - `Type=oneshot` — systemd waits for the process to *exit* before considering the unit started. This is the type for a job that does one thing and finishes. Paired with `RemainAfterExit=yes` it produces the state that confuses everyone: `active (exited)`, meaning "the job ran successfully and there is deliberately no process". Without `RemainAfterExit=`, a successful oneshot ends `inactive (dead)`. - `Type=forking` — for daemons that background themselves; systemd waits for the initial process to exit and treats a surviving child as the service, usually assisted by `PIDFile=`. - `Type=dbus` — the unit is ready when the name in `BusName=` appears on the bus. - `Type=idle` — like simple, but delays execution slightly so console output does not interleave with other startup messages. ## Reading the state names `systemctl status` and `systemctl is-active` speak a small vocabulary that pays to know exactly: `activating` (the start job is still running — for `Type=notify` this is where a slow starter sits), `active (running)` (a process exists), `active (exited)` (a oneshot completed and `RemainAfterExit=yes` is set), `deactivating`, `inactive (dead)`, and `failed`. A unit stuck in `activating (start)` is almost always a `Type=notify` service that never sent `READY=1`, or a `Type=forking` unit whose PID file never appeared. ## The practical fix for the reported symptom If you own the code, implement `sd_notify(0, "READY=1")` and switch the unit to `Type=notify` — this is the only mechanism that makes systemd's notion of "started" match your application's. If you do not own it, `Type=exec` at least makes exec failures honest, and the real readiness signal has to come from whatever consumes the service rather than from the unit state.