restructure

technology/linux/systemd/Systemd-Mounts.md

@@ -0,0 +1,27 @@
+---
+obj: concept
+---
+
+Mounts are _systemd_ unit files with a suffix of _.mount_. A unit configuration file whose name ends in ".mount" encodes information about a file system mount point controlled and supervised by systemd.
+
+Mount Unit files like every unit file include the `[Unit]` and `[Install]` sections. Additionally all mount information is in the `[Mount]` section.
+
+## Mount Section
+Fields inside the mount section:
+- `What` : Takes an absolute path of a device node, file or other resource to mount
+- `Where` : Takes an absolute path of a file or directory for the mount point; in particular, the destination cannot be a symbolic link. If the mount point does not exist at the time of mounting, it is created as either a directory or a file. The former is the usual case; the latter is done only if this mount is a bind mount and the source (What=) is not a directory. This string must be reflected in the unit filename (example: `mountpoint=/home/me` -> `unit file: home-me.mount`).
+- `Type` : Takes a string for the file system type. This setting is optional.
+- `Options` : Mount options to use when mounting. This takes a comma-separated list of options. This setting is optional.
+
+## Example
+```
+[Unit]
+Documentation=man:fstab(5) man:systemd-fstab-generator(8)
+SourcePath=/etc/fstab
+
+[Mount]
+What=/dev/sda1
+Where=/mnt
+Type=btrfs
+Options=nosuid,nodev,nofail,compress=zstd,ro
+```

technology/linux/systemd/Systemd-Timers.md

@@ -0,0 +1,62 @@
+---
+obj: concept
+arch-wiki: https://wiki.archlinux.org/title/Systemd/Timers
+---
+
+# Systemd Timers
+Timers are _systemd_ unit files with a suffix of _.timer_. Timers are like other unit configuration files and are loaded from the same paths but include a `[Timer]` section which defines when and how the timer activates. Timers are defined as one of two types:
+
+-   **Realtime timers** (a.k.a. wallclock timers) activate on a calendar event, the same way that cronjobs do. The option `OnCalendar=` is used to define them.
+-   **Monotonic timers** activate after a time span relative to a varying starting point. They stop if the computer is temporarily suspended or shut down. There are number of different monotonic timers but all have the form: `On_Type_Sec=`. Common monotonic timers include `OnBootSec` and `OnUnitActiveSec`.
+
+For each _.timer_ file, a matching _.service_ file exists (e.g. `foo.timer` and `foo.service`). The _.timer_ file activates and controls the _.service_ file. The _.service_ does not require an `[Install]` section as it is the _timer_ units that are enabled. If necessary, it is possible to control a differently-named unit using the `Unit=` option in the timer's `[Timer]` section.
+
+List timers:
+```shell
+systemctl list-timers
+```
+
+## Examples
+### Monotonic timer
+
+A timer which will start 15 minutes after boot and again every week while the system is running.
+
+`/etc/systemd/system/foo.timer`
+```
+[Unit]
+Description=Run foo weekly and on boot
+
+[Timer]
+OnBootSec=15min
+OnUnitActiveSec=1w
+
+[Install]
+WantedBy=timers.target
+```
+
+### Realtime timer
+
+A timer which starts once a week (at 12:00am on Monday). When activated, it triggers the service immediately if it missed the last start time (option `Persistent=true`), for example due to the system being powered off:
+
+`/etc/systemd/system/foo.timer`
+```
+[Unit]
+Description=Run foo weekly
+
+[Timer]
+OnCalendar=weekly
+Persistent=true
+
+[Install]
+WantedBy=timers.target
+```
+
+When more specific dates and times are required, `OnCalendar` events uses the following format:
+
+`DayOfWeek Year-Month-Day Hour:Minute:Second`
+
+An asterisk may be used to specify any value and commas may be used to list possible values. Two values separated by `..` indicate a contiguous range.
+
+In the below example the service is run the first four days of each month at 12:00 PM, but _only_ if that day is a Monday or a Tuesday.
+
+`OnCalendar=Mon,Tue *-*-01..04 12:00:00`

technology/linux/systemd/Systemd.md

@@ -0,0 +1,151 @@
+---
+website: https://systemd.io
+arch-wiki: https://wiki.archlinux.org/title/systemd
+wiki: https://en.wikipedia.org/wiki/Systemd
+repo: https://github.com/systemd/systemd
+obj: application
+---
+
+# Systemd
+systemd is a suite of basic building blocks for a [Linux](Linux.md) system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using [Linux](Linux.md) control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. systemd supports SysV and LSB init scripts and works as a replacement for sysvinit. Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.
+
+See also:
+- [Systemd-Timers](Systemd-Timers.md)
+- [systemd-boot](systemd-boot.md)
+
+## Using Units
+Units commonly include, but are not limited to, services (_.service_), mount points (_.mount_), devices (_.device_) and sockets (_.socket_).
+
+Show Status:
+```shell
+systemctl status
+systemctl status unit
+```
+
+List running units:
+```shell
+systemctl list-units
+```
+
+List failed units:
+```shell
+systemctl --failed
+```
+
+Start unit:
+```shell
+systemctl start unit
+```
+
+Stop unit:
+```shell
+systemctl stop unit
+```
+
+Restart unit:
+```shell
+systemctl restart unit
+```
+
+Reload units:
+```shell
+systemctl daemon-reload
+```
+
+Enable/Disable (Start at boot) unit:
+```shell
+systemctl enable unit
+systemctl disable unit
+```
+
+Mask (forbid running) unit:
+```shell
+systemctl mask unit
+systemctl unmask unit
+```
+
+## Power Management
+Shut down and reboot the system
+`systemctl reboot`
+
+Shut down and power-off the system
+`systemctl poweroff`
+
+Suspend the system
+`systemctl suspend`
+
+Put the system into hibernation
+`systemctl hibernate`
+
+Put the system into hybrid-sleep state (or suspend-to-both)
+`systemctl hybrid-sleep`
+
+## Unit Files
+Stored in:
+-   `/usr/lib/systemd/system/`: units provided by installed packages
+-   `/etc/systemd/system/`: units installed by the system administrator
+-   `~/.config/systemd/user/`: units used by local users
+
+### Service types
+There are several different start-up types to consider when writing a custom service file. This is set with the `Type=` parameter in the `[Service]` section:
+
+-   `Type=simple` (default): _systemd_ considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.
+-   `Type=forking`: _systemd_ considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify `PIDFile=` as well so _systemd_ can keep track of the main process.
+-   `Type=oneshot`: this is useful for scripts that do a single job and then exit. You may want to set `RemainAfterExit=yes` as well so that _systemd_ still considers the service as active after the process has exited.
+-   `Type=notify`: identical to `Type=simple`, but with the stipulation that the daemon will send a signal to _systemd_ when it is ready. The reference implementation for this notification is provided by _libsystemd-daemon.so_.
+-   `Type=dbus`: the service is considered ready when the specified `BusName` appears on DBus's system bus.
+-   `Type=idle`: _systemd_ will delay execution of the service binary until all jobs are dispatched. Other than that behavior is very similar to `Type=simple`.
+
+#### Example
+```
+[Unit]
+Description=Description
+After=network.target
+
+[Service]
+User=user
+Environment="ONE=one" 'TWO=two two'
+ExecStart=/bin
+WorkingDirectory=/
+ExecReload=/bin/sh -c "kill -HUP $MAINPID"
+KillSignal=SIGTERM
+TimeoutStopSec=30s
+SendSIGKILL=yes
+LimitNOFILE=4096
+
+[Install]
+WantedBy=multi-user.target
+```
+
+### The `[Unit]` section
+The Unit sectoin contains details and description about the unit itself. In our case, it contains details about the service. Details like 'what is it's description', 'what are it's dependencies' and more.
+
+Below are the fields the Unit section has:
+-   `Description`: Human-readable title of the systemd service.
+-   `After`: Set dependency on a service. For example, if you are configuring Apache web server, you want the server to start after the network is online. This typically includes targets or other services.
+-   `Before`: Start current service before specified service. This too, like `After`, includes targets or other services.
+
+### The `[Service]` section
+The Service section contains details about the execution and termination of service.
+
+Below are the fields the Service section can have:
+-   `ExecStart`: The command that needs to be executed when the service starts.
+-   `ExecReload`: This is an optional field. It specifies how a service is restarted. For services that perform disk I/O (especially writing to disk, like a database), it is best to gracefully kill them and start again. Use this field in case you wish to have a specific restart mechanism.
+-   `Type`: The process start-up type for this systemd service. Options are `simple`, `exec`, `forking`, `oneshot`, `dbus`, `notify` and `idle`.
+-   `Restart`: This is another optional field but one that you will very likely use. This specifies if a service should be restarted--depending on circumstances--or not. The available options are `no`, `on-success`, `on-failure`, `on-abnormal`, `on-watchdog`, `on-abort` and `always`.
+- `Environment`: [Environment Variables](Environment%20Variables.md)
+- `User`: The user that should run the process
+- `WorkingDirectory`: Working directory of the process
+
+### The `[Install]` section
+The Install section, as the name says, handles the installation of a systemd service/unit file. This is used when you run either `systemctl enable` and `systemctl disable` command for enable/disable a service.
+
+Below are the fields the Install section has:
+-   `WantedBy`: This is similar to the `After` and `Before` fields, but the main difference is that this is used to specify systemd-equivalent "runlevels". The `default.target` is when all the system initialization is complete--when the user is asked to log in. Most user-facing services (like Apache, cron, GNOME-stuff, etc) use this target.
+-   `RequiredBy`: This field might feel very similar to `WantedBy`, but the main difference is that this field specifies _hard dependencies_. Meaning, if a dependency, this service will fail.
+
+### Other Unit Types
+Systemd supports other unit types than `.service`. 
+Some include:
+- [Systemd-Timers](Systemd-Timers.md)
+- [Systemd-Mounts](Systemd-Mounts.md)

technology/linux/systemd/systemd-boot.md

@@ -0,0 +1,60 @@
+---
+obj: application
+arch-wiki: https://wiki.archlinux.org/title/Systemd-boot
+---
+
+# Systemd Boot
+systemd-boot is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu to be navigated via arrow keys. It is included with [systemd](systemd/Systemd.md), which is installed on an Arch system by default.
+
+It is simple to configure but can only start EFI executables such as the [Linux](Linux.md) kernel EFISTUB, UEFI shell, GRUB, or the [Windows](../../windows/Windows.md) Boot Manager.
+
+## Install
+Install:
+```shell
+bootctl install
+```
+
+Update:
+```shell
+bootctl update
+```
+
+## Configuration
+The loader configuration is stored in the file `_esp_/loader/loader.conf`
+Example:
+```
+default  arch.conf
+timeout  4
+console-mode max
+editor   no
+```
+
+### Adding loaders
+_systemd-boot_ will search for boot menu items in `_esp_/loader/entries/*.conf`
+
+Values:
+- `title` : Name
+- `version` : Kernel Version
+- `efi` : EFI Executable
+- `options` : Kernel Parameter
+
+Example:
+`_esp_/loader/entries/arch.conf`
+```
+title   Arch Linux
+linux   /vmlinuz-linux
+initrd  /intel-ucode.img
+initrd  /initramfs-linux.img
+options root="LABEL=_arch_os_" rw
+```
+
+## Changing Boot
+Choosing next boot:
+```shell
+systemctl reboot --boot-loader-entry=arch-custom.conf
+```
+
+Firmware Setup:
+```shell
+systemctl reboot --firmware-setup
+```