浏览代码

Documentation update: use of `base` dependency, `up` is not a shell script

Signed-off-by: Laurent Bercot <[email protected]>
Laurent Bercot 3 年之前
父节点
当前提交
bbfc841054
共有 2 个文件被更改,包括 28 次插入10 次删除
  1. 3 1
      MOVING-TO-V3.md
  2. 25 9
      README.md

+ 3 - 1
MOVING-TO-V3.md

@@ -91,7 +91,9 @@ directory: it has a `run` script, possibly a `finish` script, etc.
 needs an `up` file, but don't write your script in it. Instead, put your
 needs an `up` file, but don't write your script in it. Instead, put your
 script in another executable file, in a place of your choice (for instance
 script in another executable file, in a place of your choice (for instance
 `/etc/s6-overlay/scripts/foobar`, and just put `/etc/s6-overlay/scripts/foobar`
 `/etc/s6-overlay/scripts/foobar`, and just put `/etc/s6-overlay/scripts/foobar`
-in your `up` file.
+in your `up` file. *Be aware that `up` is __not__ a shell script*, and will not
+honor shebangs; for the details, look for `weird syntax` in the
+[README file](README.md).
     + To get your service _foo_ properly started at container boot time, you need
     + To get your service _foo_ properly started at container boot time, you need
 to add it to the `user` bundle: `touch /etc/s6-overlay/s6-rc.d/user/contents.d/foo`.
 to add it to the `user` bundle: `touch /etc/s6-overlay/s6-rc.d/user/contents.d/foo`.
 Also, to ensure it's started at the proper time, you should make it depend on
 Also, to ensure it's started at the proper time, you should make it depend on

+ 25 - 9
README.md

@@ -349,7 +349,13 @@ longrun
 nginx -g "daemon off;"
 nginx -g "daemon off;"
 ```
 ```
 
 
-`/etc/s6-overlay/s6-rc.d/user/contents.d/myapp`: empty file
+`/etc/s6-overlay/s6-rc.d/user/contents.d/myapp`: empty file.
+(This adds `myapp` to the set of services that s6-rc will start at
+container boot.)
+
+`/etc/s6-overlay/s6-rc.d/myapp/dependencies.d/base`: empty file.
+(This tells s6-rc to only start `myapp` when all the base services
+are ready: it prevents race conditions.)
 
 
 We encourage you to switch to the new format, but if you don't need its
 We encourage you to switch to the new format, but if you don't need its
 benefits, you can stick with regular service directories in `/etc/services.d`,
 benefits, you can stick with regular service directories in `/etc/services.d`,
@@ -486,8 +492,11 @@ confd --onetime --prefix="${CONFD_PREFIX}" --tmpl-uid="${UID}" --tmpl-gid="${GID
 This way is still supported. However, there is now a more generic and
 This way is still supported. However, there is now a more generic and
 efficient way to do it: writing your oneshot initialization and finalization
 efficient way to do it: writing your oneshot initialization and finalization
 tasks as s6-rc services, by adding service definition directories in
 tasks as s6-rc services, by adding service definition directories in
-`/etc/s6-overlay/s6-rc.d` and making them part of the `user` bundle. All
-the information on s6-rc can be found [here](https://skarnet.org/software/s6-rc/).
+`/etc/s6-overlay/s6-rc.d`, making them part of the `user` bundle (so they
+are actually started when the container boots), and making them depend on
+the `base` bundle (so they are only started after `base`).
+
+All the information on s6-rc can be found [here](https://skarnet.org/software/s6-rc/).
 
 
 When the container is started, the operations are performed in this order:
 When the container is started, the operations are performed in this order:
 
 
@@ -495,7 +504,10 @@ When the container is started, the operations are performed in this order:
 - (legacy) One-shot initialization scripts in `/etc/cont-init.d` are run sequentially.
 - (legacy) One-shot initialization scripts in `/etc/cont-init.d` are run sequentially.
 - Services in the `user` bundle are started by s6-rc, in an order defined by
 - Services in the `user` bundle are started by s6-rc, in an order defined by
 dependencies. Services can be oneshots (initialization
 dependencies. Services can be oneshots (initialization
-tasks) or longruns (daemons that will run throughout the container's lifetime).
+tasks) or longruns (daemons that will run throughout the container's lifetime). If
+the services depend on `base`, they are guaranteed to start at this point and not
+earlier; if they do not, they might have been started earlier, which may cause
+race conditions - so it's recommended to always make them depend on `base`.
 - (legacy) Longrun services in `/etc/services.d` are started.
 - (legacy) Longrun services in `/etc/services.d` are started.
 - Services in the `user2` bundle with the correct dependency are started.
 - Services in the `user2` bundle with the correct dependency are started.
 (Most people don't need to use this; if you are not sure, stick to the `user` bundle.)
 (Most people don't need to use this; if you are not sure, stick to the `user` bundle.)
@@ -610,6 +622,8 @@ exec logutil-service /var/log/myapp
 
 
 And here is the same service, myapp, implemented in s6-rc.
 And here is the same service, myapp, implemented in s6-rc.
 
 
+`/etc/s6-overlay/s6-rc.d/myapp-log-prepare/dependencies.d/base`: empty file
+
 `/etc/s6-overlay/s6-rc.d/myapp-log-prepare/type`:
 `/etc/s6-overlay/s6-rc.d/myapp-log-prepare/type`:
 ```
 ```
 oneshot
 oneshot
@@ -668,6 +682,8 @@ language [here](https://skarnet.org/software/execline/).
 </p>
 </p>
 </details>
 </details>
 
 
+`/etc/s6-overlay/s6-rc.d/myapp/dependencies.d/base`: empty file
+
 `/etc/s6-overlay/s6-rc.d/myapp/type`:
 `/etc/s6-overlay/s6-rc.d/myapp/type`:
 ```
 ```
 longrun
 longrun
@@ -685,6 +701,8 @@ exec mydaemon-in-the-foreground-and-logging-to-stderr
 myapp-log
 myapp-log
 ```
 ```
 
 
+`/etc/s6-overlay/s6-rc.d/myapp-log/dependencies.d/myapp-log`: empty file
+
 `/etc/s6-overlay/s6-rc.d/myapp-log/type`:
 `/etc/s6-overlay/s6-rc.d/myapp-log/type`:
 ```
 ```
 longrun
 longrun
@@ -701,11 +719,6 @@ exec logutil-service /var/log/myapp
 myapp
 myapp
 ```
 ```
 
 
-`/etc/s6-overlay/s6-rc.d/myapp-log/dependencies`:
-```
-myapp-log-prepare
-```
-
 `/etc/s6-overlay/s6-rc.d/myapp-log/pipeline-name`:
 `/etc/s6-overlay/s6-rc.d/myapp-log/pipeline-name`:
 ```
 ```
 myapp-pipeline
 myapp-pipeline
@@ -722,6 +735,9 @@ are longruns, i.e. daemons that will be supervised by s6.
 - The `myapp | myapp-log` pipeline is given a name, `myapp-pipeline`, and
 - The `myapp | myapp-log` pipeline is given a name, `myapp-pipeline`, and
 this name is declared as a part of the `user` bundle, so it will be started
 this name is declared as a part of the `user` bundle, so it will be started
 when the container starts.
 when the container starts.
+- `myapp-log-prepare`, `myapp-log` and `myapp` all depend on the `base`
+bundle, which means they will only be started when the system is actually
+ready to start them.
 
 
 It really accomplishes the same things as the `/etc/cont-init.d` plus
 It really accomplishes the same things as the `/etc/cont-init.d` plus
 `/etc/services.d` method, but it's a lot cleaner underneath, and can handle
 `/etc/services.d` method, but it's a lot cleaner underneath, and can handle