{"id":76,"date":"2022-03-27T16:23:28","date_gmt":"2022-03-27T20:23:28","guid":{"rendered":"http:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/?p=76"},"modified":"2024-10-11T09:36:00","modified_gmt":"2024-10-11T13:36:00","slug":"systemctl-systemd-commands","status":"publish","type":"post","link":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/?p=76","title":{"rendered":"systemctl \/ systemd commands"},"content":{"rendered":"\n<h3 class=\"wp-block-heading\"><a><\/a>Starting and Stopping Services<\/h3>\n\n\n\n<p>To start a <code>systemd<\/code> service, executing instructions in the service\u2019s unit file, use the <code>start<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl start application.service<\/li><\/ul>\n\n\n\n<p><code>Since<\/code><code>systemd<\/code> knows to look for <code>*.service<\/code> files for service management commands, so the command could just as easily be typed like this:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl start application<\/li><\/ul>\n\n\n\n<p>To stop a currently running service, you can use the <code>stop<\/code> command instead:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl stop application.service<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Restarting and Reloading<\/h3>\n\n\n\n<p>To restart a running service, you can use the <code>restart<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl restart application.service<\/li><\/ul>\n\n\n\n<p>If the application in question is able to reload its configuration files (without restarting), you can issue the <code>reload<\/code> command to initiate that process:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl reload application.service<\/li><\/ul>\n\n\n\n<p>If you are unsure whether the service has the functionality to reload its configuration, you can issue the <code>reload-or-restart<\/code> command. This will reload the configuration in-place if available. Otherwise, it will restart the service so the new configuration is picked up:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl reload-or-restart application.service<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Enabling and Disabling Services<\/h3>\n\n\n\n<p>To start a service at boot, use the <code>enable<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl enable application.service<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><\/h3>\n\n\n\n<p>This will create a symbolic link from the system\u2019s copy of the service file, usually in <code>\/lib\/systemd\/system<\/code> or <code>\/etc\/systemd\/system<\/code>) into the location on disk where <code>systemd<\/code> looks for autostart files (usually <code>\/etc\/systemd\/system\/some_target.target.wants<\/code>.<\/p>\n\n\n\n<p>To disable the service from starting automatically, you can type:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl disable application.service<\/li><\/ul>\n\n\n\n<p>This will remove the symbolic link.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Enabling and Starting Services together<\/h3>\n\n\n\n<p>To enable and start a service in one command, use<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl enable application.service &#8211;now<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Checking the Status of Services<\/h3>\n\n\n\n<p>To check the status of a service on your system, you can use the <code>status<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl status application.service<\/li><\/ul>\n\n\n\n<p>There are also methods for checking for specific states. For instance, <strong>to check to see if a unit is currently active <\/strong>(running), you can use the <code>is-active<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl is-active application.service<\/li><\/ul>\n\n\n\n<p>This will return the current unit state, which is usually <code>active<\/code> or <code>inactive<\/code>. The exit code will be \u201c0\u201d if it is active, making the result simpler to parse in shell scripts.<\/p>\n\n\n\n<p><strong>To see if the unit is enabled<\/strong>, you can use the <code>is-enabled<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl is-enabled application.service<\/li><\/ul>\n\n\n\n<p>This will output whether the service is <code>enabled<\/code> or <code>disabled<\/code> and will again set the exit code to \u201c0\u201d or \u201c1\u201d depending on the answer to the command question.<\/p>\n\n\n\n<p>A third check is <strong>whether the unit is in a failed state<\/strong>. This indicates that there was a problem starting the unit in question:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl is-failed application.service<\/li><\/ul>\n\n\n\n<p>This will return <code>active<\/code> if it is running properly or <code>failed<\/code> if an error occurred. If the unit was intentionally stopped, it may return <code>unknown<\/code> or <code>inactive<\/code>. An exit status of \u201c0\u201d indicates that a failure occurred and an exit status of \u201c1\u201d indicates any other status.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><a><\/a>System State Overview<\/h2>\n\n\n\n<p>The commands so far have been useful for managing single services, but they are not very helpful for exploring the current state of the system. There are a number of <code>systemctl<\/code> commands that provide this information.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Listing Current Units<\/h3>\n\n\n\n<p>To see a list of all of the active units that <code>systemd<\/code> knows about, we can use the <code>list-units<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl list-units<\/li><\/ul>\n\n\n\n<p>This will show you a list of all of the units that <code>systemd<\/code> currently has active on the system. The output will look something like this:<\/p>\n\n\n\n<p>Output<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><code>UNIT                                      LOAD   ACTIVE SUB     DESCRIPTION<\/code>\n<code>atd.service                               loaded active running ATD daemon<\/code>\n<code>avahi-daemon.service                      loaded active running Avahi mDNS\/DNS-SD Stack<\/code>\n<code>dbus.service                              loaded active running D-Bus System Message Bus<\/code>\n<code>dcron.service                             loaded active running Periodic Command Scheduler<\/code>\n<code>dkms.service                              loaded active exited  Dynamic Kernel Modules System<\/code>\n<code>getty@tty1.service                        loaded active running Getty on tty1<\/code>\n<code>. . .<\/code><\/pre>\n\n\n\n<p>The output has the following columns:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>UNIT<\/strong>: The <code>systemd<\/code> unit name<\/li><li><strong>LOAD<\/strong>: Whether the unit\u2019s configuration has been parsed by <code>systemd<\/code>. The configuration of loaded units is kept in memory.<\/li><li><strong>ACTIVE<\/strong>: A summary state about whether the unit is active. This is usually a fairly basic way to tell if the unit has started successfully or not.<\/li><li><strong>SUB<\/strong>: This is a lower-level state that indicates more detailed information about the unit. This often varies by unit type, state, and the actual method in which the unit runs.<\/li><li><strong>DESCRIPTION<\/strong>: A short textual description of what the unit is\/does.<\/li><\/ul>\n\n\n\n<p>Since the <code>list-units<\/code> command shows only active units by default, all of the entries above will show <code>loaded<\/code> in the LOAD column and <code>active<\/code> in the ACTIVE column. This display is actually the default behavior of <code>systemctl<\/code> when called without additional commands, so you will see the same thing if you call <code>systemctl<\/code> with no arguments:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl<\/li><\/ul>\n\n\n\n<p>We can tell <code>systemctl<\/code> to output different information by adding additional flags. For instance, to see all of the units that <code>systemd<\/code> has loaded (or attempted to load), regardless of whether they are currently active, you can use the <code>--all<\/code> flag, like this:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl list-units &#8211;all<\/li><\/ul>\n\n\n\n<p>This will show any unit that <code>systemd<\/code> loaded or attempted to load, regardless of its current state on the system. Some units become inactive after running, and some units that <code>systemd<\/code> attempted to load may have not been found on disk.<\/p>\n\n\n\n<p>You can use other flags to filter these results. For example, we can use the <code>--state=<\/code> flag to indicate the LOAD, ACTIVE, or SUB states that we wish to see. You will have to keep the <code>--all<\/code> flag so that <code>systemctl<\/code> allows non-active units to be displayed:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl list-units &#8211;all &#8211;state=inactive<\/li><\/ul>\n\n\n\n<p>Another common filter is the <code>--type=<\/code> filter. We can tell <code>systemctl<\/code> to only display units of the type we are interested in. For example, to see only active service units, we can use:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl list-units &#8211;type=service<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Listing All Unit Files<\/h3>\n\n\n\n<p>The <code>list-units<\/code> command only displays units that <code>systemd<\/code> has attempted to parse and load into memory. Since <code>systemd<\/code> will only read units that it thinks it needs, this will not necessarily include all of the available units on the system. To see <em>every<\/em> available unit file within the <code>systemd<\/code> paths, including those that <code>systemd<\/code> has not attempted to load, you can use the <code>list-unit-files<\/code> command instead:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl list-unit-files<\/li><\/ul>\n\n\n\n<p>Units are representations of resources that <code>systemd<\/code> knows about. Since <code>systemd<\/code> has not necessarily read all of the unit definitions in this view, it only presents information about the files themselves. The output has two columns: the unit file and the state.<\/p>\n\n\n\n<p>Output<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><code>UNIT FILE                                  STATE   <\/code>\n<code>proc-sys-fs-binfmt_misc.automount          static  <\/code>\n<code>dev-hugepages.mount                        static  <\/code>\n<code>dev-mqueue.mount                           static  <\/code>\n<code>proc-fs-nfsd.mount                         static  <\/code>\n<code>proc-sys-fs-binfmt_misc.mount              static  <\/code>\n<code>sys-fs-fuse-connections.mount              static  <\/code>\n<code>sys-kernel-config.mount                    static  <\/code>\n<code>sys-kernel-debug.mount                     static  <\/code>\n<code>tmp.mount                                  static  <\/code>\n<code>var-lib-nfs-rpc_pipefs.mount               static  <\/code>\n<code>org.cups.cupsd.path                        enabled<\/code>\n<code>. . .<\/code><\/pre>\n\n\n\n<p>The state will usually be <code>enabled<\/code>, <code>disabled<\/code>, <code>static<\/code>, or <code>masked<\/code>. In this context, static means that the unit file does not contain an <code>install<\/code> section, which is used to enable a unit. As such, these units cannot be enabled. Usually, this means that the unit performs a one-off action or is used only as a dependency of another unit and should not be run by itself.<\/p>\n\n\n\n<p>We will cover what <code>masked<\/code> means momentarily.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><a><\/a>Unit Management<\/h2>\n\n\n\n<p>So far, we have been working with services and displaying information about the unit and unit files that <code>systemd<\/code> knows about. However, we can find out more specific information about units using some additional commands.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Displaying a Unit File<\/h3>\n\n\n\n<p>To display the unit file that <code>systemd<\/code> has loaded into its system, you can use the <code>cat<\/code> command (this was added in <code>systemd<\/code> version 209). For instance, to see the unit file of the <code>atd<\/code> scheduling daemon, we could type:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl cat atd.service<\/li><\/ul>\n\n\n\n<p>Output<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><code>[Unit]<\/code>\n<code>Description=ATD daemon<\/code>\n<code>[Service]<\/code>\n<code>Type=forking<\/code>\n<code>ExecStart=\/usr\/bin\/atd<\/code>\n<code>[Install]<\/code>\n<code>WantedBy=multi-user.target<\/code><\/pre>\n\n\n\n<p>The output is the unit file as known to the currently running <code>systemd<\/code> process. This can be important if you have modified unit files recently or if you are overriding certain options in a unit file fragment (we will cover this later).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Displaying Dependencies<\/h3>\n\n\n\n<p>To see a unit\u2019s dependency tree, you can use the <code>list-dependencies<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl list-dependencies sshd.service<\/li><\/ul>\n\n\n\n<p>This will display a hierarchy mapping the dependencies that must be dealt with in order to start the unit in question. Dependencies, in this context, include those units that are either required by or wanted by the units above it.<\/p>\n\n\n\n<p>Output<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><code>sshd.service<\/code>\n<code>\u251c\u2500system.slice<\/code>\n<code>\u2514\u2500basic.target<\/code>\n<code>  \u251c\u2500microcode.service<\/code>\n<code>  \u251c\u2500rhel-autorelabel-mark.service<\/code>\n<code>  \u251c\u2500rhel-autorelabel.service<\/code>\n<code>  \u251c\u2500rhel-configure.service<\/code>\n<code>  \u251c\u2500rhel-dmesg.service<\/code>\n<code>  \u251c\u2500rhel-loadmodules.service<\/code>\n<code>  \u251c\u2500paths.target<\/code>\n<code>  \u251c\u2500slices.target<\/code>\n<code>. . .<\/code><\/pre>\n\n\n\n<p>The recursive dependencies are only displayed for <code>.target<\/code> units, which indicate system states. To recursively list all dependencies, include the <code>--all<\/code> flag.<\/p>\n\n\n\n<p>To show reverse dependencies (units that depend on the specified unit), you can add the <code>--reverse<\/code> flag to the command. Other flags that are useful are the <code>--before<\/code> and <code>--after<\/code> flags, which can be used to show units that depend on the specified unit starting before and after themselves, respectively.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Checking Unit Properties<\/h3>\n\n\n\n<p>To see the low-level properties of a unit, you can use the <code>show<\/code> command. This will display a list of properties that are set for the specified unit using a <code>key=value<\/code> format:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl show sshd.service<\/li><\/ul>\n\n\n\n<p>Output<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><code>Id=sshd.service<\/code>\n<code>Names=sshd.service<\/code>\n<code>Requires=basic.target<\/code>\n<code>Wants=system.slice<\/code>\n<code>WantedBy=multi-user.target<\/code>\n<code>Conflicts=shutdown.target<\/code>\n<code>Before=shutdown.target multi-user.target<\/code>\n<code>After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice<\/code>\n<code>Description=OpenSSH server daemon<\/code>\n<code>. . .<\/code><\/pre>\n\n\n\n<p>If you want to display a single property, you can pass the <code>-p<\/code> flag with the property name. For instance, to see the conflicts that the <code>sshd.service<\/code> unit has, you can type:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl show sshd.service -p Conflicts<\/li><\/ul>\n\n\n\n<p>Output<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Conflicts=shutdown.target<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Masking and Unmasking Units<\/h3>\n\n\n\n<p>We saw in the service management section how to stop or disable a service, but <code>systemd<\/code> also has the ability to mark a unit as <em>completely<\/em> unstartable, automatically or manually, by linking it to <code>\/dev\/null<\/code>. This is called masking the unit, and is possible with the <code>mask<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl mask nginx.service<\/li><\/ul>\n\n\n\n<p>This will prevent the Nginx service from being started, automatically or manually, for as long as it is masked.<\/p>\n\n\n\n<p>If you check the <code>list-unit-files<\/code>, you will see the service is now listed as masked:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl list-unit-files<\/li><\/ul>\n\n\n\n<p>Output<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><code>. . .<\/code>\n<code>kmod-static-nodes.service              static  <\/code>\n<code>ldconfig.service                       static  <\/code>\n<code>mandb.service                          static  <\/code>\n<code>messagebus.service                     static  <\/code>\n<code>nginx.service                          masked<\/code>\n<code>quotaon.service                        static  <\/code>\n<code>rc-local.service                       static  <\/code>\n<code>rdisc.service                          disabled<\/code>\n<code>rescue.service                         static<\/code>\n<code>. . .<\/code><\/pre>\n\n\n\n<p>If you attempt to start the service, you will see a message like this:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl start nginx.service<\/li><\/ul>\n\n\n\n<p>Output<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Failed to start nginx.service: Unit nginx.service is masked.<\/code><\/pre>\n\n\n\n<p>To unmask a unit, making it available for use again, use the <code>unmask<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl unmask nginx.service<\/li><\/ul>\n\n\n\n<p>This will return the unit to its previous state, allowing it to be started or enabled.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><a><\/a>Editing Unit Files<\/h2>\n\n\n\n<p>While the specific format for unit files is outside of the scope of this tutorial, <code>systemctl<\/code> provides built-in mechanisms for editing and modifying unit files if you need to make adjustments. This functionality was added in <code>systemd<\/code> version 218.<\/p>\n\n\n\n<p>The <code>edit<\/code> command, by default, will open a unit file snippet for the unit in question:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl edit nginx.service<\/li><\/ul>\n\n\n\n<p>This will be a blank file that can be used to override or add directives to the unit definition. A directory will be created within the <code>\/etc\/systemd\/system<\/code> directory which contains the name of the unit with <code>.d<\/code> appended. For instance, for the <code>nginx.service<\/code>, a directory called <code>nginx.service.d<\/code> will be created.<\/p>\n\n\n\n<p>Within this directory, a snippet will be created called <code>override.conf<\/code>. When the unit is loaded, <code>systemd<\/code> will, in memory, merge the override snippet with the full unit file. The snippet\u2019s directives will take precedence over those found in the original unit file.<\/p>\n\n\n\n<p>If you wish to edit the full unit file instead of creating a snippet, you can pass the <code>--full<\/code> flag:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl edit &#8211;full nginx.service<\/li><\/ul>\n\n\n\n<p>This will load the current unit file into the editor, where it can be modified. When the editor exits, the changed file will be written to <code>\/etc\/systemd\/system<\/code>, which will take precedence over the system\u2019s unit definition (usually found somewhere in <code>\/lib\/systemd\/system<\/code>).<\/p>\n\n\n\n<p>To remove any additions you have made, either delete the unit\u2019s <code>.d<\/code> configuration directory or the modified service file from <code>\/etc\/systemd\/system<\/code>. For instance, to remove a snippet, we could type:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo rm -r \/etc\/systemd\/system\/nginx.service.d<\/li><\/ul>\n\n\n\n<p>To remove a full modified unit file, we would type:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo rm \/etc\/systemd\/system\/nginx.service<\/li><\/ul>\n\n\n\n<p>After deleting the file or directory, you should reload the <code>systemd<\/code> process so that it no longer attempts to reference these files and reverts back to using the system copies. You can do this by typing:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl daemon-reload<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><a><\/a> Adjusting the System State (Runlevel) with Targets<\/h2>\n\n\n\n<p>Targets are special unit files that describe a system state or synchronization point. Like other units, the files that define targets can be identified by their suffix, which in this case is <code>.target<\/code>. Targets do not do much themselves, but are instead used to group other units together.<\/p>\n\n\n\n<p>This can be used in order to bring the system to certain states, much like other init systems use runlevels. They are used as a reference for when certain functions are available, allowing you to specify the desired state instead of the individual units needed to produce that state.<\/p>\n\n\n\n<p>For instance, there is a <code>swap.target<\/code> that is used to indicate that swap is ready for use. Units that are part of this process can sync with this target by indicating in their configuration that they are <code>WantedBy=<\/code> or <code>RequiredBy=<\/code> the <code>swap.target<\/code>. Units that require swap to be available can specify this condition using the <code>Wants=<\/code>, <code>Requires=<\/code>, and <code>After=<\/code> specifications to indicate the nature of their relationship.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a> Getting and Setting the Default Target<\/h3>\n\n\n\n<p>The <code>systemd<\/code> process has a default target that it uses when booting the system. Satisfying the cascade of dependencies from that single target will bring the system into the desired state. To find the default target for your system, type:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl get-default<\/li><\/ul>\n\n\n\n<p>Output<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>multi-user.target<\/code><\/pre>\n\n\n\n<p>If you wish to set a different default target, you can use the <code>set-default<\/code>. For instance, if you have a graphical desktop installed and you wish for the system to boot into that by default, you can change your default target accordingly:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl set-default graphical.target<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Listing Available Targets<\/h3>\n\n\n\n<p>You can get a list of the available targets on your system by typing:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl list-unit-files &#8211;type=target<\/li><\/ul>\n\n\n\n<p>Unlike runlevels, multiple targets can be active at one time. An active target indicates that <code>systemd<\/code> has attempted to start all of the units tied to the target and has not tried to tear them down again. To see all of the active targets, type:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl list-units &#8211;type=target<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a>Isolating Targets<\/h3>\n\n\n\n<p>It is possible to start all of the units associated with a target and stop all units that are not part of the dependency tree. The command that we need to do this is called, appropriately, <code>isolate<\/code>. This is similar to changing the runlevel in other init systems.<\/p>\n\n\n\n<p>For instance, if you are operating in a graphical environment with <code>graphical.target<\/code> active, you can shut down the graphical system and put the system into a multi-user command line state by isolating the <code>multi-user.target<\/code>. Since <code>graphical.target<\/code> depends on <code>multi-user.target<\/code> but not the other way around, all of the graphical units will be stopped.<\/p>\n\n\n\n<p>You may wish to take a look at the dependencies of the target you are isolating before performing this procedure to ensure that you are not stopping vital services:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>systemctl list-dependencies multi-user.target<\/li><\/ul>\n\n\n\n<p>When you are satisfied with the units that will be kept alive, you can isolate the target by typing:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl isolate multi-user.target<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><a><\/a> Using Shortcuts for Important Events<\/h3>\n\n\n\n<p>There are targets defined for important events like powering off or rebooting. However, <code>systemctl<\/code> also has some shortcuts that add a bit of additional functionality.<\/p>\n\n\n\n<p>For instance, to put the system into rescue (single-user) mode, you can just use the <code>rescue<\/code> command instead of <code>isolate rescue.target<\/code>:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl rescue<\/li><\/ul>\n\n\n\n<p>This will provide the additional functionality of alerting all logged in users about the event.<\/p>\n\n\n\n<p>To halt the system, you can use the <code>halt<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl halt<\/li><\/ul>\n\n\n\n<p>To initiate a full shutdown, you can use the <code>poweroff<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl poweroff<\/li><\/ul>\n\n\n\n<p>A restart can be started with the <code>reboot<\/code> command:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo systemctl reboot<\/li><\/ul>\n\n\n\n<p>These all alert logged in users that the event is occurring, something that only running or isolating the target will not do. Note that most machines will link the shorter, more conventional commands for these operations so that they work properly with <code>systemd<\/code>.<\/p>\n\n\n\n<p>For example, to reboot the system, you can usually type:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>sudo reboot<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Starting and Stopping Services To start a systemd service, executing instructions in the service\u2019s unit file, use the start command: sudo systemctl start application.service Sincesystemd knows to look for *.service files for service management commands, so the command could just as easily be typed like this: sudo systemctl start application To stop a currently running [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15,13],"tags":[],"class_list":["post-76","post","type-post","status-publish","format-standard","hentry","category-file-management","category-os-maintenance"],"_links":{"self":[{"href":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/76","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=76"}],"version-history":[{"count":1,"href":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/76\/revisions"}],"predecessor-version":[{"id":77,"href":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/76\/revisions\/77"}],"wp:attachment":[{"href":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=76"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=76"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/triosdevelopers.com\/J.Smith\/rjeffsmith.ca\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=76"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}