doc: massive refactor and simplification to migrate to mkdocs

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

doc/service.md

@@ -1,15 +1,13 @@
-Finit Services
-==============
-
 Starting & Monitoring
----------------------
+=====================
 
 Finit can start and monitor the following types of daemons:
 
 * Forks to background, creates a PID file
-* Runs in foreground:
-  - creates a PID file
+* Runs in foreground and signals ready by:
+  - creating a PID file
   - does not create a PID file -- Finit can create it for you (optional)
+  - [other mechanism][1] (systemd, s6)
 
 Finit can *not* start and monitor a daemon that:
 
@@ -24,9 +22,10 @@ Finit can *not* start and monitor a daemon that:
 
 > [!NOTE]
 > PID files is one mechanism used to assert conditions to synchronize
-> the start and stop of other, dependent, services.
+> the start and stop of other, dependent, services.  Other mechanisms
+> are described in the [Service Synchronization][1] section.
 
-### Forks to Background w/ PID File
+### Forks to bg w/ PID file
 
 There are two syntax variants, type 1 and type 2.  The former is the
 traditional one used also for `sysv` start/stop scripts, and the latter
@@ -40,49 +39,19 @@ In this example the resulting files to watch for are `/run/serv.pid` and
 `/var/run/serv.pid`, respectively.  On most modern Linux systems this is
 the same directory (`/var/run` is a symlink to `../run`).
 
-### Runs in Foreground w/ PID File
+### Runs in fg w/ PID file
 
     service                    serv -n -p -- Foreground service w/ PID file
 
-### Runs in Foreground w/o PID File
+### Runs in fg w/o PID file
 
 Same as previous, but we tell Finit to create the PID file, because we
 need it to synchronize start/stop of a dependent service.
 
     service pid:/run/serv.pid  serv -n    -- Foreground service w/o PID file
 
-### Runs in Foreground w/ Custom PID File
+### Runs in fg w/ custom PID file
 
     service pid:/run/servy.pid serv -n -p -P /run/servy.pid -- Foreground service w/ custom PID file
 
-
-State Machine
--------------
-
-A service is bound to a state machine that is in one of six (6) states.
-For `run`s and `task`s there is an additional end state called `DONE`,
-not shown in the diagram for brevity.  Services start in the `HALTED`
-state.
-
-![The service state machine](svc-machine.png "The service state machine")
-
-The current state depends on the two following conditions:
-
-* `E`: Service enabled. In order for `E` to be satisfied, the service
-  must be allowed to run in the current runlevel and not be stopped.
-  
-  A service may be stopped, or blocked, for several reasons:
-
-  - The user has manually stopped the service using `initctl stop NAME`
-  - The program exits immediately. I.e. keeps crashing (make sure to use
-    the 'run this service in the foreground' command line option)
-  - The binary is missing in the filesystem
-
-* `C`: Service conditions are satisfied:
-
-  - `on` (+): The condition is asserted.
-  - `off` (-): The condition is deasserted.
-  - `flux` (~): The condition state is unknown.
-
-For a detailed description of conditions, and how to debug them,
-see the [Finit Conditions](conditions.md) document.
+[1]: config/service-sync.md