Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== Making Changes to Daemon Files ======
+Whenever a daemon file is changed in ''/etc/systemd/system/'', the daemon files must be reloaded with:
+<code bash>
+systemctl daemon-reload
+</code>
+====== Starting Programs on Virtual Terminals ======
+Most *nix derivates start a login program such as ''getty'' on multiple virtual terminals for the user to log-in when the system boots. On pre-systemd systems, ''/etc/inittab'' was used to spawn (and re-spawn) ''getty'' on the virtual terminals, which could also be used to run console programs such as ''htop'' instead of the login terminal.
+The procedure with systemd is a little different and involves shutting down the tty services and creating a service file. The first thing to do is run:
+<code bash>
+systemctl
+</code>
+and search (using forward-slash ''/'' and typing in text to search) for ''getty''. On a Debian system, one would find:
+<code>
+  getty@tty1.service                                                          loaded active running   Getty on tty2
+  getty@tty2.service                                                          loaded active running   Getty on tty2
+  getty@tty6.service                                                          loaded active running   Getty on tty6
+</code>
+which means that ''getty'' will be spawned on ''tty1'', ''tty2'' and ''tty6''. Whilst ''tty6'' has a special meaning and is a fallback console to always provide the means for an operator to log-in, ''tty1'' and ''tty2'' could be used to spawn a different program such as ''htop''.
+In order for ''getty'' and ''htop'' to not race each other, the first step is to stop and disable the ''getty@tty1.service'' service:
+<code bash>
+systemctl stop getty@tty1.service
+systemctl disable getty@tty1.service
+</code>
+Next, add the following contents to a file placed at ''/etc/systemd/system/htop.service'':
+<code>
+[Unit]
+Description=htop on tty1
+[Service]
+Type=simple
+ExecStart=/usr/bin/htop
+StandardInput=tty
+StandardOutput=tty
+TTYPath=/dev/tty1
+Restart=always
+RestartSec=2
+[Install]
+WantedBy=getty.target
+</code>
+where:
+  * ''/dev/tty1'' is the virtual terminal to start ''htop'' on.
+You can now enable and start the service via:
+<code bash>
+systemctl enable htop.service
+systemctl start htop.service
+</code>
+and ''htop'' should appear on the first virtual terminal.
+====== Set Runlevel ======
+The SystemD version of ''init 3'':
+<code bash>
+systemctl isolate multi-user.target
+</code>
+and the ''init 4'' version:
+<code bash>
+systemctl isolate graphical.target
+</code>
+====== Make Service Depend on Network Interface ======
+Given a service file and a network interface (for example, ''br0''), the service file can be modified such that the service file runs only after the network interface (''br0'') is up and running.
+In order to do so, issue the command:
+<code>
+systemctl list-units --no-pager
+</code>
+that will list all the systemd units and look for ''br0''.
+If it is a configured network interface, then something along the lines:
+<code>
+sys-devices-virtual-net-br0.device loaded active plugged   /sys/devices/virtual/net/br
+</code>
+will be printed by the previous command.
+In order to modify the service file, add ''sys-devices-virtual-net-br0.device'' to the ''[Unit]'' section of the service file:
+<code>
+[Unit]
+BindsTo=sys-devices-virtual-net-br0.device
+After=sys-devices-virtual-net-br0.device
+</code>
+====== Create a Custom Target ======
+A custom target can be created that will run at the end when all other services have completed. This is useful to ensure that running a program is the last thing that is performed as part of the boot up process.
+Let's assume that the target name will be "microscope" that will have to run after the ''multi-user'' target has been reached, and by reaching the ''microscrope'' target, several programs will have to be started in the background.
+First, the target is defined by creating a target file at ''/etc/systemd/system/microscope.target'' with the following contents:
+<code>
+[Unit]
+Description=Microscope Target
+Requires=multi-user.target
+After=multi-user.target
+AllowIsolate=yes
+</code>
+Now, the "microscope" target might want some service files to run when it is reached, such that the folder ''/etc/systemd/system/microscope.target.wants'' is created. Any service file that needs to run programs has to be linked into the ''/etc/systemd/system/microscope.target.wants'' folder. For example, let's create a service file at ''/etc/systemd/system/microscope.service'' with the following contents:
+<code>
+[Unit]
+Description=Microscope
+After=microscope_clone.service
+Before=microscope_button.service
+[Service]
+ExecStart=/usr/bin/ffmpeg -hide_banner -loglevel quiet -f v4l2 -video_size 640x420 -i /dev/video50 -pix_fmt rgb565le -f fbdev /dev/fb0
+Restart=always
+RestartSec=10
+StandardOutput=syslog
+StandardError=syslog
+SyslogIdentifier=microscope
+User=root
+Group=root
+Environment=PATH=/usr/bin/:/usr/local/bin/
+[Install]
+WantedBy=microscope.target
+</code>
+The service file starts ''ffmpeg'' with some parameters and depends on two different service files ''microscope_clone.service'' and ''microscope_button.service''. All the files are now linked into the wants of the ''microscope'' target:
+<code bash>
+ln -sf /etc/systemd/system/{microscope_clone,microscope,microscope_button}.service /etc/systemd/system/microscope.target.wants/
+</code>
+To make sure the changes are picked up, SystemD will be reloaded:
+<code bash>
+systemctl daemon-reload
+</code>
+Finally, the final target can be re-mapped from the default ''multi-user'' target to the new ''microscope'' target:
+<code bash>
+systemctl set-default microscope.target
+</code>
+The machine can be now either be rebooted or the changes can be applied immediately by issuing:
+<code bash>
+systemctl isolate microscope.target
+</code>
+====== Attempting to Start a Service Indefinitely ======
+The following configuration:
+<code>
+[Unit]
+StartLimitIntervalSec=0
+[Service]
+RestartSec=10
+</code>
+when added to a service file, will have the effect of attempting to start the service successfully indefinitely by attempting a start the service every ''10'' seconds until it succeeds.
+====== Custom Service Folders ======
+One of the cool thing that one could do would be to specify alternative directories to hold service files that are meant for groups of services pertaining to projects. Currently, the location to place service files using SystemD is ''/etc/systemd/system/'' but that directory contains a lot of Linux' kitchen, with some of the files and links being managed by Linux setup scripts, such that adding files there does not feel too proper.
+The solution is to specify an additional service file path at boot time. In order to do this, create the directory path ''/etc/systemd/system.conf.d/'' and the file ''/etc/systemd/system.conf.d/systemd.conf'' with the following contents:
+<code bash>
+[Manager]
+ManagerEnvironment="SYSTEMD_UNIT_PATH=/mnt/docker/services:"
+</code>
+where:
+  * ''/mnt/docker/services'' is the path to a directory containing the desired SystemD service files
+Note that the colon at the end '':'' will tell SystemD to append this path instead of substituting the system path with the user-specified path, which is exactly what was desired.
+After a system reboot, service or unit files ca be placed in, following the example, the directory ''/mnt/docker/services'' and then loaded using the ''systemctl'' command. This achieves a very nice [[/fuss/computer_engineering#copying_large_files|separation of concerns]] between the system managed service files, custom service files meant for projects, as well as user service files.