no way to compare when less than two revisions

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.