Lines Matching refs:service

101 service: daemon controlled by a service monitor.
103 service directory: a directory with an executable file (script) named "run"
108 service monitor: a tool which watches a set of service directories.
111 Service monitor starts a supervisor for each service directory.
112 If it dies, it restarts it. If service directory disappears,
113 service monitor will not be restarted if it dies.
114 runit's service monitor (runsvdir) sends SIGTERM to supervisors
117 supervisor: a tool which monitors one service directory.
124 the supervisor component: service monitor can directly monitor all its daemons
126 However all three existing projects (daemontools/runit/s6) do have a per-service
129 log service: a service which is exclusively tasked with logging
130 the output of another service. It is implemented as log/ subdirectory
131 in a service directory. It has the same structure as "normal"
132 service dirs: it has a "run" script which starts a logging tool.
134 If log service exists, stdout of its "main" service is piped
135 to log service. Stops/restarts of either of them do not sever the pipe
138 If log service exists, daemontools and s6 run a pair of supervisors
140 per service, which is handling both of them (presumably this is done
146 "Users" of service monitoring are authors of software which has daemons.
151 System-wide service dirs reside in a distro-specific location.
152 The recommended location is /var/service. (However, since it is not
155 by making /var/service a symlink).
157 The install location for service dirs is /etc/rc:
163 directory (common choice are /var/service, /run/service etc).
167 all logging from all daemons through service monitor process
172 location of its service directories. (For example,
173 /var/service may be a symlink to /etc/rc).
180 (2) Creation of a new service can race with the rescanning of /etc/rc/
181 by service monitor: service monitor may see a directory with only some files
182 present. If it attempts to start the service in this state, all sorts
184 heuristics in service monitor which give new service a few seconds
204 An especially primitive service which does not want its output to be logged
213 To prevent creation of distro-specific log/ directory, a service directory
220 In particular, often one service needs to control another:
222 and it needs to (re)start DHCP service for this network device.
243 relative to the system-wide service directory.
249 The "svok DIR" tool exits 0 if service supervisor is running
250 (with service itself either running or stopped), and nonzero if not.
255 Creation of a new service on a running system should be done atomically.
259 depending on the distro) its files to the "live" service directory,
262 Removal of the service should be done as follows:
263 svc -d DIR [DIR/log], then remove the service directory:
264 this makes service monitor SIGTERM per-directory supervisors
270 Top-level service monitor program name is not standardized
282 does not affect the running service (unless it is renamed to a .dotdir).
286 Standard output of non-logged services goes to standard output of service monitor.
287 Standard output of logger services goes to standard output of service monitor.
288 Standard error of them always goes to standard error of service monitor.
290 If you want to log standard error of your logged service along with its stdout, use
293 Whether stdout/stderr of service monitor is discarded (>/dev/null)