Not Found
The requested item could not be located.
The requested item could not be located.
The requested item could not be located.
| info | The minimalistic Run-time Configuration (RC) system and process manager |
There are a few options for the communication:
The minimalistic Run-time Configuration (RC) system and process manager is written in pure BASH and uses just a few external utilities like ls, ps, date and sleep. Minimally, installation of TrivialRC consists of only one file which can be downloaded directly from the Github. Originaly, it was designed for use in containers but it also can be well used for running a group of processes asynchronously and synchronously, as well as managing their running order and exit codes.
TrivialRC is not a replacement for an init process that usually resides in /sbin/init and has a PID 1. In containers for this purpose projects like dumb-init or tini can be used, although in most cases, having only TrivialRC as a first/main process (PID 1) in containers is quite enough. In terms of Docker, the best place for it is ENTRYPOINT.
TrivialRC is an equivalent to well known /etc/rc for xBSD users. The RC system that is used for managing startup and shutdown processes. It can start and stop one or more processes, in parallel or sequentially, on back- or foreground, react differently in case of process failures, etc. All commands can be specified in the command line if they are relatively simple, or in separate files if a more comprehensive scenario is needed. That's why it can be used as a simplest tool for managing a group of process and be a lightweight replacement for solutions like Supervisor.
For instance, in docker images when TrivialRC is used as an Entrypoint, it doesn't reveal itself by default, does not affect any configuration and behaves absolutely transparently. So, you can add it into any Dockerfiles which do not have an entrypoint yet and get by this the full control under processes with fairly detailed logs of what's is going on inside a container. Please, take a look at examples for more information.
Basically, all you need to install TrivialRC is download the latest release of the script from http://trivialrc.vorakl.com/trc and give it an execute permission. By default, it looks for configuration files in the same directory from which it was invoked but this behavior can be changed by setting a work directory (-w|--workdir parametr). So, if you are going to use configuration files and keep them in /etc/, then you would probably want to install the script to /etc/ as well and simply run it without specifying any parametrs.
Another option in this case could be to install the script in a more appropriate path but don't forget to specify --workdir /etc parametr every time when you invoke this rc system. Both options are possible and depend more on a particular use case. For instance, in case of using in a docker container, I personaly prefer to have all configuration in separate files in trc.d/ sub-directory and copy it together with the script in /etc/.
This is an example of how it would look in a Dockerfile with centos:latest as base image:
FROM centos:latest
2 |
3 | RUN curl -sSLfo /etc/trc http://trivialrc.vorakl.com/trc && \
4 | ( cd /etc && curl -sSLf http://trivialrc.vorakl.com/trc.sha256 | sha256sum -c ) && \
5 | chmod +x /etc/trc && \
6 | /etc/trc --version
7 |
8 | # Uncomment this if you have configuration files in trc.d/
9 | # COPY trc.d/ /etc/trc.d/
10 |
11 | ENTRYPOINT ["/etc/trc"]
12 | Attention! The Alpine Linux comes with Busybox but its functionality as a shell and as a few emulated tools is not enough for TrivialRC. To work in this distribution it requires two extra packages: bash and procps. As a result, Dockerfile for the alpine:latest base image would look like:
FROM alpine:latest
13 |
14 | RUN apk add --no-cache bash procps
15 |
16 | RUN wget -qP /etc/ http://trivialrc.vorakl.com/trc && \
17 | ( cd /etc && wget -qO - http://trivialrc.vorakl.com/trc.sha256 | sha256sum -c ) && \
18 | chmod +x /etc/trc && \
19 | /etc/trc --version
20 |
21 | # Uncomment this if you have configuration files in trc.d/
22 | # COPY trc.d/ /etc/trc.d/
23 |
24 | ENTRYPOINT ["/etc/trc"]
25 | To get started and find out some features, basically, I suggest to go through all available examples and read their readmes plus comments along the code but to start from one-liners which show most common use cases and features.
It is important to notice that the order of command line options is not equal to their run order. In general it looks like:
$ trc [-h|--help] [-v|--version] [-w|--workdir 'dir'] [-B 'cmds' [...]] [-H 'cmds' [...]] [-D 'cmds' [...]] [-F 'cmds' [...]] [command [args]]
26 | Where
So, command line options have to be supplied in the next order
Examples:
$ trc -B 'name=$(id -un); echo booting...' -H 'echo halting...' -F 'echo Hello, ${name}!'
27 |
28 | $ RC_WAIT_POLICY=wait_all trc -D 'echo Hello' -D 'sleep 2; echo World' echo waiting...
29 |
30 | $ RC_VERBOSE=true trc -F 'echo -n "Hello "; echo World'
31 |
32 | $ trc --workdir /opt/app
33 | The life cycle of TrivialRC consists of different stages, with different isolation. By default, all configuration files (or trc.d/ directory with them) are searched in the directory from which was executed trc itself. For instance, if you've installed trc in /usr/bin/ and run it by using only its name, like trc, then configuration will also be searched in /usr/bin/. Though, you can place configuration files anywhere you like and specify their location in the -w|--workdir option, like trc -w /etc/.
Let's check:
$ which trc
34 | /usr/bin/trc
35 |
36 | $ trc -B 'echo $work_dir'
37 | /usr/bin
38 |
39 | $ trc -w /etc -B 'echo $work_dir'
40 | /etc
41 | All stages are executed through in the next order:
Execution order: trc.boot.* -> trc.d/boot.* -> [-B 'cmds' [...]]
Commands run in a same environment as the main process and that's why it has to be used with caution. It's useful for setting up global variables which are seen in all other isolated environments.
Execution order: trc.async.* -> trc.d/async.* -> [-D 'cmds' [...]]
Commands run in the separate environment, asynchronously (all run in parallel), in the background and do not affect the main process. If you are going to run more than one async commands, don't forget that default RC_WAIT_POLICY is set to 'wait_any' and the executing process will be stopped after the first finished command and only if there wasn't any running foreground (sync) command that could block the reaction on the TERM signal. So, there are two options:
Execution order: trc.sync.* -> trc.d/sync.* -> [-F 'cmds' [...]] -> [cmd]
Commands run in the separate environment, synchronously (one by one), in the foreground and do not affect the main process. if you are going to run more than one sync commands, don't forget to change RC_WAIT_POLICY to 'wait_all' or 'wait_err', otherwise, the executing process will be stopped after the first command.
Execution order: trc.halt.* -> trc.d/halt.* -> [-H 'cmds' [...]]
Commands run in the separate environment, synchronously (one by one) when the main process is finishing (on exit). An exit status from the last halt command has precedence under an exit status from the main process which was supplied as ${_exit_status} variable. So you are able to keep a main exit status (by finishing as exit ${_exit_status}) or rewrite it to something else but anyway, if you have at least one halt command, TrivialRC will finish with an exit status of this halt command.
The rc system reacts differently when one of controlled processes finishes. Depending on the value of RC_WAIT_POLICY environment variable it makes a decision when exactly it should stop itself. The possible values are:
By default, TrivailRC doesn't print any service messages at all. It only sends stdout and stderr of all isolated sub-shells to the same terminal. If another behavior is needed, you can redirect any of them inside each sub-shell separately. To increase the verbosity of rc system there are provided a few environment variables:
You can also use some of internal functions in async/sync tasks: