My New Hugo Site

  1. Bash
    1. Filters
      1. grep
      2. Sed
      3. jq
    2. Shellspec
  2. Design
  3. Architectural Patterns
    1. Systemd
    2. Message Broker
    3. JSON-RPC
  4. Go
    1. Concurrency
    2. Web Applications
    3. Compound Data
    4. Json
    5. Go vs Erlang
  5. Prolog Cookbook
  6. Documentation
    1. Hugo
      1. Go Html Template
      2. Table of Contents
    2. HTML
    3. CSS
      1. Color
      2. Style Guides
      3. Layout
    4. Mathjax
  7. Visualization
    1. D3
      1. Venn Diagrams
    2. SVG
    3. Visjs
      1. Network
  8. Data
    1. Yaml
    2. Events
      1. JSON-LD
    3. JSON
      1. jCal
    4. SQL
  9. JavaScript

Systemd

systemctl list-unit-files

To get the available service types, enter:

systemctl --type=help

At time of writing, it responds with:

  1. service
  2. mount
  3. swap
  4. socket
  5. target
  6. device
  7. automount
  8. timer
  9. path
  10. slice
  11. scope

These types correspond to the file suffixes expected for unit files, eg /etc/systemd/system/appname.service.

Their description can be found via

man systemd.service
man systemd.socket
man systemd.device
man systemd.mount
man systemd.automount
man systemd.swap
man systemd.target
man systemd.path
man systemd.timer
man systemd.slice
man systemd.scope

Unit files

The details are given by man systemd.unit

A unit file is a plain text ini-style file which describe various service types. A template for a service unit file would look like:

# Systemd unit file for example application
[Unit]
Description=Service Description
After=syslog.target network.target

[Service]
Type=simple
Restart=always
RestartSec=30s
User=user
Group=group
WorkingDirectory=/path/to/working-directory
ExecStart=/path/to/working-directory/./golang-application

[Install]
WantedBy=multi-user.target

The [Unit] and [Install] sections are common to all, while [Service], [Socket], [Device], etc depend on the service type.

Unit section

Description=A short human readable title of the unit.
Documentation=https://www.nginx.com/resources/wiki/start/topics/examples/systemd/
Before=If unit foo.service contains the setting Before=bar.service and both units are being started, bar.service's start-up is delayed until foo.service has finished starting up.
After=Inverse of Before=
Wants=network-online.target
Requires=Similar to Wants=, but declares a stronger requirement dependency.
Requisite=Units listed here have to have been started for this to start.
BindsTo=If the unit bound to is stopped, this unit will be stopped too.
PartOf=When systemd stops or restarts the units listed here, the action is propagated to this unit.
Upholds=All units listed are started whenever found to be inactive or failed
Conflicts=If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa.
OnFailure=
OnSuccess=
PropagatesReloadTo=, ReloadPropagatedFrom=
...

It appears everying Erlang’s supervision tree does has been implemented in systemd.

Install section

This section is not interpreted by systemd(1) during runtime; it is used by the enable and disable commands of the systemctl(1) tool during installation of a unit.