| Command | Description |
| systemctl stop service-name | systemd stop running service |
| systemctl start service-name | systemctl start service |
| systemctl restart service-name | systemd restart running service |
| systemctl reload service-name | reloads all config files for service |
| systemctl status service-name | systemctl show if service is running |
| systemctl enable service-name | systemctl start service at boot |
| systemctrl disable service-name | systemctl - disable service at boot |
| systemctl show service-name | show systemctl service info |
| systemctl -H target command service-name | run systemctl commands remotely |
Systemd commands that show useful system information.
| Command | Description |
| systemctl list-dependencies | show and units dependencies |
| systemctl list-sockets | systemd list sockets and activities |
| systemctl list-jobs | view active systemd jobs |
| systemctl list-unit-files | systemctl list unit files and their states |
| systemctl list-units | systemctl list default target (like run level) |
systemd reboot, shutdown, default target etc
| Command | Description |
| systemctl reboot | systemctl reboot the system |
| systemctl poweroff | systemctl shutdown (power off the system) |
| systemctl emergency | Put in emergency mode |
| systemctl default | systemctl default mode |
| Command | Description |
| journalctl | show all collected log messages |
| journalctl -u sshd.service | see sshd service messages |
| journalctl -f | follow messages as they appear |
| journalctl -k | show kernel messages only |
BY default, journalctl only keep last boot logs.
journalctl --boot=-1 Failed to look up boot -1: Cannot assign requested address
To change that behaviour:
vim /etc/systemd/journald.conf
[Journal] Storage=auto
en
[Journal] Storage=persistent
then
mkdir /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal systemctl restart systemd-journald
Now you can see all boots logs
journalctl --list-boots -1 a234ea246c48442bb54c2e7e57695949 Thu 2017-04-20 20:47:42 CEST—Thu 2017-04-20 21:21:49 CEST 0 374475d934e540b3a04a8db0887778d3 Thu 2017-04-20 21:22:33 CEST—Thu 2017-04-20 21:32:49 CEST
To see last boot (-1, 0 is current boot)
journalctl --boot=-1
| Option | Description |
| `PrivateTmp=yes` | Creates a file system namespace under `/tmp/systemd-private-*-[unit name]-*/tmp` rather than a shared `/tmp` or `/var/tmp`. Many of the unit files that ship with Red Hat Enterprise Linux include this setting and it removes an entire class of vulnerabilities around the prediction and replacement of files used in `/tmp`. |
| `PrivateNetwork=` | Provides a network namespace for the service with only a loopback interface available. A great option for applications that do not require external network communication. |
| `SELinuxContext=` | Runs the application in a specific context. This option is a good idea for defining when a policy is available for applications shipped outside of RHEL. A good SELinux primer is [available here](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/using_selinux/index). |
| `NoNewPrivileges=` | Prevents the service and related child processes from escalating privileges. |
| `ProtectSystem=yes` | Makes `/usr` and `/boot` read-only to the application. Setting this option to `full` also makes `/etc` read-only. In Red Hat Enterprise Linux 8, there’s an additional option called `strict` that also makes `/dev`, `/proc`, and `/sys` read-only. |
| `ProtectHome=yes` | Makes `/home`, `/root`, and `/run/user` appear empty. An additional option is `read-only`, which does exactly what it says. Also new to RHEL 8, `tmpfs` will overlay a writeable, ephemeral file system at these points. Because these directories are used to store SSH keys and other potentially sensitive information, it’s a good idea to prohibit applications from having access. |
| `ProtectDevices=yes` | Creates a private `/dev` namespace containing only pseudo devices like `/dev/null` and `/dev/random`, which do not give access to actual hardware. It also disables `CAP_MKNOD` so that new device nodes cannot be created. |
| `CapabilityBoundingSet=` | Accepts a whitelist and blacklist of privileged capabilities for the unit. Linux capabilities break down the root user access to the system so privileged access can be better pinpointed. The classic example is for NTP or `chrony` to be able to configure the system clock but take no other privileged actions. More details are available in the capabilities (7) man page. |
| `ReadWriteDirectories=` `ReadOnlyDirectories=` `InaccessibleDirectories=` | Behaves similarly to `ProtectSystem`, but all three of these options allow fine-grained control of file system access. |
| ProtectKernelTunables=yes | Disables modification of /proc and /sys. |
| ProtectKernelModules=yes | Prohibits loading or unloading modules and masks /usr/lib/modules from the application. |
| ProtectControlGroups=yes | Disables write access to /sys/fs/cgroup/. |
| RestrictNamespaces= | Restrict all or a subset of namespaces to the service. Accepts cgroup, ipc, net, mnt, pid, user, and uts. |
| AssertSecurity= | Takes a number of requirements that must be met by the system for the service to start. If the listed capabilities are not available the service will fail to run and the event is logged. Options like selinux and uefi-secureboot are useful for many environments. |
| MemoryDenyWriteExecute= | Disables memory mapping that is simultaneously writeable and executable. |
| RestrictRealtime=yes | Prohibits real-time scheduling. |
| PrivateMounts=yes | Causes the service to run in a private mount namespace. |
| DynamicUser=yes | Effectively creates a transient user for the application. This option probably warrants its own post to explore, but briefly, the systemd implementation is brilliant because it dynamically (as the name suggests) creates a UID and GID by plugging in an nss module that “creates” the user on the fly. These users simply don’t exist when the service isn’t running. This feature is most useful for stateless applications, but directories can be mapped in for writing to. |
| SystemCallFilter= | Lets you whitelist and blacklist individual syscalls or use the user-friendly groups of calls that systemd provides. If you are familiar with seccomp filtering with containers, this option provides the exact same thing. In a general sense, most users will find the @system-service filter valuable, which enables the relevant system calls needed by most services. Users can view the list of groups and available system calls by running systemd-analyze syscall-filter. |