commit 04c1126e0d9b11896948a4716500292f03e04dcf
parent ec0f90726a728f12336b9990a8cd22684d6da495
Author: Cem Keylan <cem@ckyln.com>
Date: Sat, 4 Jul 2020 00:20:18 +0300
replace README
Diffstat:
| D | README | | | 158 | ------------------------------------------------------------------------------- |
| D | README.org | | | 121 | ------------------------------------------------------------------------------- |
| A | README.txt | | | 15 | +++++++++++++++ |
3 files changed, 15 insertions(+), 279 deletions(-)
diff --git a/README b/README
@@ -1,158 +0,0 @@
- ________
-
- SYSMGR
- ________
-
-
-
-
-
-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
-
-shinit
-~~~~~~
-
- Yet another example that we do not need lots of complexity. [shinit]
- is an example init daemon in POSIX sh, yet again proving that shell is
- sufficient for system management. `shinit' and `sysmgr' go along
- really good.
-
-
-[shinit] https://github.com/cemkeylan/shinit
-
-
-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
- `----
-
-
-Utilities
-=========
-
- `utils' directory is for non-essential tools that can be used
- alongside `sysmgr'.
-
-
-sysmgr-needs
-~~~~~~~~~~~~
-
- `sysmgr-needs' waits for the given service/s to start up. It was
- inspired by the [Life without systemd] section of the [Busybox
- Homepage] which mentions a `/bin/need' script that waits for a
- file/directory/socket to exist.
-
- You can incorporate this tool in your service scripts like this
-
- ,----
- | #!/bin/sh
- | sysmgr-needs dbus || exit 1
- | exec NetworkManager -n >/dev/null 2>&1
- `----
-
-
-[Life without systemd] https://www.busybox.net/kill_it_with_fire.txt
-
-[Busybox Homepage] https://www.busybox.net
diff --git a/README.org b/README.org
@@ -1,121 +0,0 @@
-#+TITLE: SYSMGR
-#+OPTIONS: num:nil toc:nil author:nil
-
-* Table of Contents :TOC:noexport:
-- [[#rationale][Rationale]]
- - [[#shinit][shinit]]
-- [[#overview][Overview]]
- - [[#usage][Usage]]
- - [[#current-functions][Current Functions]]
- - [[#switching-from-runit][Switching from Runit]]
-- [[#utilities][Utilities]]
- - [[#sysmgr-needs][sysmgr-needs]]
-
-* Rationale
-
-System-supervision is often seen as the most complicated
-part of managing a system. This is in part due to projects
-like [[https://github.com/systemd/systemd][systemd]] and [[https://wiki.gentoo.org/wiki/Project:OpenRC][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.
-
-[[https://smarden.org/runit][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.
-
-** shinit
-
-Yet another example that we do not need lots of complexity.
-[[https://github.com/cemkeylan/shinit][shinit]] is an example init daemon in POSIX sh, yet again proving
-that shell is sufficient for system management. =shinit= and =sysmgr=
-go along really good.
-
-* 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):
-
-#+BEGIN_SRC sh
-#!/bin/sh
-exec /usr/bin/sshd -D
-#+END_SRC
-
-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
-
-#+BEGIN_SRC sh
-# 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
-#+END_SRC
-* Utilities
-
-=utils= directory is for non-essential tools that can be used alongside
-=sysmgr=.
-
-** sysmgr-needs
-
-=sysmgr-needs= waits for the given service/s to start up. It was inspired
-by the [[https://www.busybox.net/kill_it_with_fire.txt][Life without systemd]] section of the [[https://www.busybox.net][Busybox Homepage]] which mentions
-a =/bin/need= script that waits for a file/directory/socket to exist.
-
-You can incorporate this tool in your service scripts like this
-
-#+BEGIN_SRC sh
-#!/bin/sh
-sysmgr-needs dbus || exit 1
-exec NetworkManager -n >/dev/null 2>&1
-#+END_SRC
diff --git a/README.txt b/README.txt
@@ -0,0 +1,15 @@
+SYSMGR
+--------------------------------------------------------------------------------
+
+SYSMGR is a service manager for Linux written in POSIX shell. It reads the
+service scripts from the given SYSDIR (which is '/var/sysmgr' by default) and
+executes them asynchronously via RUNSYSSV. While exiting it sends a hangup
+signal to all RUNSYSSV processes.
+
+
+Directory structure
+--------------------------------------------------------------------------------
+
+ docs/ -- Documentation
+ man/ -- Manual pages
+ utils/ -- C programs
