# Anatomy of a typical target

Targets are in fact daemontools-style services too.

The normal service in the regular services collection is an example of a target. Its `start`, `stop`, `run`, and `restart` programs all simply exit "true". In the case of the `run` program, this would normally result in the program being repeatedly re-executed by the service manager.

The "remain" flag file tells `system-control`, however, to set a "run on empty" flag for this service when loading it. This causes the service manager to consider the service to be still in the running state even if its last service process has exited. (Normally, exiting the last service process causes a state transition, via the failed state either back to the running state or to the stopped state.) Thus targets show up in the output of service-status as running services with no process ID.

(An alternative way of creating a target is to not use the "remain" flag but to use the `pause` built-in command in nosh. This has the usually undesirable effect of having an indefinitely running process in the process list that is sitting swapped out and doing nothing. But it has the advantage of not having the service manager treat it as a special "run on empty" service, which cannot be adjusted at runtime after a target has been loaded, and permitting the target to actually do something concrete if so desired.)

The major part of a target is in its service bundle. The normal target's service bundle causes the normal target to also encompass the "server", "workstation", "basic", "multi-user", "static-networking", and "users" targets (and everything that they themselves, in their turns, encompass). The target is stopped by "shutdown" (which doesn't mean very much because of course the target itself does very little), and is ordered in the startup sequence after the "basic" target.