commit dab7f0e742ac9477931ddbc2b97a0747118e3da1
parent a10e0b97adeaa36d701f8f7c1f72660dbaa1d285
Author: Cem Keylan <cem@ckyln.com>
Date: Thu, 27 Feb 2020 15:47:04 +0300
add README
Diffstat:
| A | README | | | 119 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 file changed, 119 insertions(+), 0 deletions(-)
diff --git a/README b/README
@@ -0,0 +1,119 @@
+ ________
+
+ SYSMGR
+ ________
+
+
+A POSIX sh system-supervisor meant to take away the complexity of
+today's alternatives
+
+
+Rationale
+=========
+
+ System-supervision is often seen as the most complicated part of
+ managing a system. This is in part due to projects like [systemd] and
+ [OpenRC]. However, those projects add some unnecessary fancy stuff and
+ code complexity. systemd is not even portable outside of
+ Linux. System-supervision does not have to be this complicated.
+
+ [Runit] is a good alternative for system-supervision. However it is
+ still too complex, and uses C, which brings me to the main point of
+ this.
+
+ A user should not be running some magic commands while not having an
+ idea of what they are doing. A program that is just running some shell
+ script should not be some complicated C program. It can just be
+ managed from another shell process, a program that just makes use of
+ basic UNIX utilities that exist on almost every system.
+
+
+[systemd] https://github.com/systemd/systemd
+
+[OpenRC] https://wiki.gentoo.org/wiki/Project:OpenRC
+
+[Runit] https://smarden.org/runit
+
+
+Overview
+========
+
+ SYSMGR is a POSIX-compliant shell program. It reads the service
+ scripts from the given SYSDIR (which is `/var/sysmgr' by default) and
+ executes them asynchronously via RUNSYSV. While exiting it sends a
+ hangup signal to all RUNSYSSV processes.
+
+
+Usage
+~~~~~
+
+ Add your service scripts to `/var/sysmgr'. An example service script
+ would be (for ssh daemon):
+
+ ,----
+ | #!/bin/sh
+ | exec /usr/bin/sshd -D
+ `----
+
+ You can then run sysmgr to start your services.
+
+
+Current Functions
+~~~~~~~~~~~~~~~~~
+
+RUNSYSSV
+--------
+
+ RUNSYSSV executes the system service and expects for signals. During
+ this state it periodically checks to make sure its given service is
+ still alive. If it is not alive RUNSYSSV removes its run directory
+ (given that there is no lockfile inside) and exits.
+
+ It is not meant to be run by the user, but there wouldn't be any
+ issues with it either. You can run a service by doing `runsyssv
+ /path/to/service' and it will run that service script given that there
+ isn't any service with the same name on the run directory. You can
+ specify a different `RUNDIR' if that is the case.
+
+
+SVCTL
+-----
+
+ SVCTL is the function with which the user interacts with SYSMGR. The
+ user will do a `svctl <command> <service-name>'. It currently has
+ useful but limited options. These are,
+ start
+ Removes the run directory for the service so that it can be
+ started.
+ restart
+ Sends a SIGTERM to the service and starts it back again.
+ stop
+ Sends a SIGTERM to the service and adds a lockfile to its run
+ directory, so that it is not restarted.
+ kill
+ Sends a SIGKILL to the service and adds a lockfile to its run
+ directory, so that it is not restarted.
+ up/down
+ Same as start/stop
+ once
+ Start the service and add a lockfile to its run directory, so
+ that it is not restarted.
+ stat/status
+ Check if the service is running or not
+
+
+Switching from Runit
+--------------------
+
+ If you want to switch from runit to sysmgr all you need to do is to
+ run this following command
+
+ ,----
+ | # Create the directory if you haven't yet
+ | mkdir -p /var/sysmgr
+ |
+ | # Copy your run scripts to /var/sysmgr
+ | for service in /var/service/* ; do
+ | cp "$service/run" "/var/sysmgr/${service##*/}"
+ | done
+ `----
