From 042b7d0e92e4cf42506c79ab6bfe504ddb08dc86 Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Mon, 27 Jul 2015 14:02:51 +0000 Subject: - Doc fixes on notification, mentions of s6-rc - version: 2.2.0.0 --- doc/servicedir.html | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) (limited to 'doc/servicedir.html') diff --git a/doc/servicedir.html b/doc/servicedir.html index 76a0a11..952882a 100644 --- a/doc/servicedir.html +++ b/doc/servicedir.html @@ -139,6 +139,30 @@ service is said to be logged; the foo/log service is foo/log/log exists, nothing special happens. +

Stability

+ +

+ With the evolution of s6, it is possible that + s6-supervise configuration uses more and more +files in the service directory. The +notification-fd and timeout-finish files, for +instance, have appeared in 2015; users who previously had files +with the same name had to change them. There is no guarantee that +s6-supervise will not use additional +names in the service directory in the same fashion in the future. +

+ +

+ There is, however, a guarantee that +s6-supervise will never touch +subdirectories named data or env. So if you +need to store user information in the service directory with +the guarantee that it will never be mistaken for a configuration +file, no matter the version of s6, you should store that information in +the data or env subdirectories of the service +directory. +

+

Where to store my service directories ?

@@ -184,7 +208,9 @@ amounts to less than a megabyte of data - sometimes much less. Knowing this, it makes sense to have an image of your service directories in the (possibly read-only) root filesystem, and copy it all to a scan directory located on a RAM filesystem that is mounted at boot time. -This is the setup I recommend. It has several advantages: +This is the setup I recommend, and the one used by the +s6-rc service manager. + It has several advantages: