While establishing a Linux system lately, I wished to know the way to make sure that dependencies for providers and different models have been up and operating earlier than these dependent providers and models begin. Specifically, I wanted extra data of how systemd manages the startup sequence, particularly in figuring out the order providers are began in what is actually a parallel system.
You might know that SystemV (systemd’s predecessor, as I defined within the first article on this sequence) orders the startup sequence by naming the startup scripts with an SXX prefix, the place XX is a quantity from 00 to 99. SystemV then makes use of the type order by title and runs every begin script in sequence for the specified runlevel.
But systemd makes use of unit recordsdata, which may be created or modified by a sysadmin, to outline subroutines for not solely initialization but in addition for normal operation. In the third article on this sequence, I defined methods to create a mount unit file. In this fifth article, I display methods to create a special kind of unit file—a service unit file that runs a program at startup. You may also change sure configuration settings within the unit file and use the systemd journal to view the situation of your modifications within the startup sequence.
Preparation
Make certain you might have eliminated rhgb and quiet from the GRUB_CMDLINE_LINUX= line within the /and so on/default/grub file, as I confirmed within the second article on this sequence. This lets you observe the Linux startup message stream, which you may want for a number of the experiments on this article.
The program
In this tutorial, you’ll create a easy program that lets you observe a message throughout startup on the console and later within the systemd journal.
Create the shell program /usr/native/bin/hiya.sh and add the next content material. You need to be sure that the result’s seen throughout startup and you can simply discover it when trying via the systemd journal. You will use a model of the “Hello world” program with some bars round it, so it stands out. Make certain the file is executable and has person and group possession by root with 700 permissions for safety:
#!/usr/bin/bash
# Simple program to make use of for testing startup configurations
# with systemd.
# By David Both
# Licensed below GPL V2
#
echo "###############################"
echo "######### Hello World! ########"
echo "###############################"
Run this program from the command line to confirm that it really works appropriately:
[root@testvm1 ~]# hiya.sh
###############################
######### Hello World! ########
###############################
[root@testvm1 ~]#
This program could possibly be created in any scripting or compiled language. The hiya.sh program may be positioned elsewhere based mostly on the Linux filesystem hierarchical structure (FHS). I place it within the /usr/native/bin listing in order that it may be simply run from the command line with out having to prepend a path after I kind the command. I discover that lots of the shell applications I create have to be run from the command line and by different instruments similar to systemd.
The service unit file
Create the service unit file /and so on/systemd/system/hiya.service with the next content material. This file doesn’t have to be executable, however for safety, it does want person and group possession by root and 644 or 640 permissions:
# Simple service unit file to make use of for testing
# startup configurations with systemd.
# By David Both
# Licensed below GPL V2
#[Unit]
Description=My hiya shell script[Service]
Type=oneshot
ExecStart=/usr/native/bin/hiya.sh[Install]
WantedBy=multi-user.goal
Verify that the service unit file performs as anticipated by viewing the service standing. Any syntactical errors will present up right here:
[root@testvm1 ~]# systemctl standing hiya.service
● hiya.service - My hiya shell script
Loaded: loaded (/and so on/systemd/system/hiya.service; disabled; vendor preset: disabled)
Active: inactive (useless)
[root@testvm1 ~]#
You can run this “oneshot” service kind a number of occasions with out issues. The oneshot kind is meant for providers the place this system launched by the service unit file is the principle course of and should full earlier than systemd begins any dependent course of.
There are seven service varieties, and you will discover a proof of every (together with the opposite components of a service unit file) within the systemd.service(5) man web page. (You may also discover extra info within the resources on the finish of this text.)
As curious as I’m, I wished to see what an error may seem like. So, I deleted the “o” from the Type=oneshot line, so it appeared like Type=neshot, and ran the command once more:
[root@testvm1 ~]# systemctl standing hiya.service
● hiya.service - My hiya shell script
Loaded: loaded (/and so on/systemd/system/hiya.service; disabled; vendor preset: disabled)
Active: inactive (useless)May 06 08:50:09 testvm1.each.org systemd[1]: /and so on/systemd/system/hiya.service:12: Failed to parse service kind, ignoring: neshot
[root@testvm1 ~]#
These outcomes advised me exactly the place the error was and made it very straightforward to resolve the issue.
Just remember that even after you restore the hiya.service file to its unique type, the error will persist. Although a reboot will clear the error, you shouldn’t have to do this, so I went in search of a technique to filter out persistent errors like this. I’ve encountered service errors that require the command systemctl daemon-reload to reset an error situation, however that didn’t work on this case. The error messages that may be fastened with this command all the time appear to have a press release to that impact, so you recognize to run it.
It is, nonetheless, really helpful that you simply run systemctl daemon-reload after altering a unit file or creating a brand new one. This notifies systemd that the modifications have been made, and it may well stop sure forms of points with managing altered providers or models. Go forward and run this command.
After correcting the misspelling within the service unit file, a easy systemctl restart hiya.service cleared the error. Experiment a bit by introducing another errors into the hiya.service file to see what sorts of outcomes you get.
Start the service
Now you might be prepared to begin the brand new service and verify the standing to see the consequence. Although you most likely did a restart within the earlier part, you can begin or restart a oneshot service as many occasions as you need because it runs as soon as after which exits.
Go forward and begin the service (as proven beneath), after which verify the standing. Depending upon how a lot you experimented with errors, your outcomes might differ from mine:
[root@testvm1 ~]# systemctl begin hiya.service
[root@testvm1 ~]# systemctl standing hiya.service
● hiya.service - My hiya shell script
Loaded: loaded (/and so on/systemd/system/hiya.service; disabled; vendor preset: disabled)
Active: inactive (useless)May 10 10:37:49 testvm1.each.org hiya.sh[842]: ######### Hello World! ########
May 10 10:37:49 testvm1.each.org hiya.sh[842]: ###############################
May 10 10:37:49 testvm1.each.org systemd[1]: hiya.service: Succeeded.
May 10 10:37:49 testvm1.each.org systemd[1]: Finished My hiya shell script.
May 10 10:54:45 testvm1.each.org systemd[1]: Starting My hiya shell script...
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ###############################
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ######### Hello World! ########
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ###############################
May 10 10:54:45 testvm1.each.org systemd[1]: hiya.service: Succeeded.
May 10 10:54:45 testvm1.each.org systemd[1]: Finished My hiya shell script.
[root@testvm1 ~]#
Notice within the standing command’s output that the systemd messages point out that the hiya.sh script began and the service accomplished. You may also see the output from the script. This show is generated from the journal entries of the latest invocations of the service. Try beginning the service a number of occasions, after which run the standing command once more to see what I imply.
You also needs to take a look at the journal contents straight; there are a number of methods to do that. One approach is to specify the document kind identifier, on this case, the title of the shell script. This reveals the journal entries for earlier reboots in addition to the present session. As you may see, I’ve been researching and testing for this text for a while now:
[root@testvm1 ~]# journalctl -t hiya.sh
<snip>
-- Reboot --
May 08 15:55:47 testvm1.each.org hiya.sh[840]: ###############################
May 08 15:55:47 testvm1.each.org hiya.sh[840]: ######### Hello World! ########
May 08 15:55:47 testvm1.each.org hiya.sh[840]: ###############################
-- Reboot --
May 08 16:01:51 testvm1.each.org hiya.sh[840]: ###############################
May 08 16:01:51 testvm1.each.org hiya.sh[840]: ######### Hello World! ########
May 08 16:01:51 testvm1.each.org hiya.sh[840]: ###############################
-- Reboot --
May 10 10:37:49 testvm1.each.org hiya.sh[842]: ###############################
May 10 10:37:49 testvm1.each.org hiya.sh[842]: ######### Hello World! ########
May 10 10:37:49 testvm1.each.org hiya.sh[842]: ###############################
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ###############################
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ######### Hello World! ########
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ###############################
[root@testvm1 ~]#
To find the systemd data for the hiya.service unit, you may search on systemd. You can use G+Enter to web page to the tip of the journal entries after which scroll again to find those you have an interest in. Use the -b possibility to point out solely the entries for the latest startup:
[root@testvm1 ~]# journalctl -b -t systemd
<snip>
May 10 10:37:49 testvm1.each.org systemd[1]: Starting SYSV: Late init script for stay picture....
May 10 10:37:49 testvm1.each.org systemd[1]: Started SYSV: Late init script for stay picture..
May 10 10:37:49 testvm1.each.org systemd[1]: hiya.service: Succeeded.
May 10 10:37:49 testvm1.each.org systemd[1]: Finished My hiya shell script.
May 10 10:37:50 testvm1.each.org systemd[1]: Starting D-Bus System Message Bus...
May 10 10:37:50 testvm1.each.org systemd[1]: Started D-Bus System Message Bus.
I copied just a few different journal entries to offer you an concept of what you may discover. This command spews all the journal strains pertaining to systemd—109,183 strains after I wrote this. That is a number of knowledge to kind via. You can use the pager’s search facility, which is normally much less, or you need to use the built-in grep function. The -g (or --grep=) possibility makes use of Perl-compatible common expressions:
[root@testvm1 ~]# journalctl -b -t systemd -g "hello"
[root@testvm1 ~]# journalctl -b -t systemd -g "hello"
-- Logs start at Tue 2020-05-05 18:11:49 EDT, finish at Sun 2020-05-10 11:01:01 EDT. --
May 10 10:37:49 testvm1.each.org systemd[1]: Starting My hiya shell script...
May 10 10:37:49 testvm1.each.org systemd[1]: hiya.service: Succeeded.
May 10 10:37:49 testvm1.each.org systemd[1]: Finished My hiya shell script.
May 10 10:54:45 testvm1.each.org systemd[1]: Starting My hiya shell script...
May 10 10:54:45 testvm1.each.org systemd[1]: hiya.service: Succeeded.
May 10 10:54:45 testvm1.each.org systemd[1]: Finished My hiya shell script.
[root@testvm1 ~]#
You may use the usual GNU grep command, however that will not present the log metadata within the first line.
If you do not need to see simply the journal entries pertaining to your hiya service, you may slender issues down a bit by specifying a time vary. For instance, I’ll begin with the start time of 10:54:00 on my take a look at VM, which was the beginning of the minute the entries above are from. Note that the --since= possibility have to be enclosed in quotes and that this selection can be expressed as -S "<time specification>".
The date and time shall be completely different in your host, so make sure to use the timestamps that match the occasions in your journals:
[root@testvm1 ~]# journalctl --since="2020-05-10 10:54:00"
May 10 10:54:35 testvm1.each.org audit: BPF prog-id=54 op=LOAD
May 10 10:54:35 testvm1.each.org audit: BPF prog-id=55 op=LOAD
May 10 10:54:45 testvm1.each.org systemd[1]: Starting My hiya shell script...
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ###############################
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ######### Hello World! ########
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ###############################
May 10 10:54:45 testvm1.each.org systemd[1]: hiya.service: Succeeded.
May 10 10:54:45 testvm1.each.org systemd[1]: Finished My hiya shell script.
May 10 10:54:45 testvm1.each.org audit[1]: SERVICE_START pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=hiya comm="systemd" exe="/usr/lib/systemd"'
May 10 10:54:45 testvm1.each.org audit[1]: SERVICE_STOP pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=hiya comm="systemd" exe="/usr/lib/systemd/"'
May 10 10:56:00 testvm1.each.org NetworkManager[840]: <error> [1589122560.0633] dhcp4 (enp0s3): error -113 dispatching occasions
May 10 10:56:00 testvm1.each.org NetworkManager[840]: <data> [1589122560.0634] dhcp4 (enp0s3): state modified certain -> fail
<snip>
The since specification skips all the entries earlier than that point, however there are nonetheless a number of entries after that point that you don’t want. You may also use the till choice to trim off the entries that come a bit after the time you have an interest in. I would like your complete minute when the occasion occurred and nothing extra:
[root@testvm1 ~]# journalctl --since="2020-05-10 10:54:35" --until="2020-05-10 10:55:00"
-- Logs start at Tue 2020-05-05 18:11:49 EDT, finish at Sun 2020-05-10 11:04:59 EDT. --
May 10 10:54:35 testvm1.each.org systemd[1]: Reloading.
May 10 10:54:35 testvm1.each.org audit: BPF prog-id=27 op=UNLOAD
May 10 10:54:35 testvm1.each.org audit: BPF prog-id=26 op=UNLOAD
<snip>
ay 10 10:54:35 testvm1.each.org audit: BPF prog-id=55 op=LOAD
May 10 10:54:45 testvm1.each.org systemd[1]: Starting My hiya shell script...
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ###############################
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ######### Hello World! ########
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ###############################
May 10 10:54:45 testvm1.each.org systemd[1]: hiya.service: Succeeded.
May 10 10:54:45 testvm1.each.org systemd[1]: Finished My hiya shell script.
May 10 10:54:45 testvm1.each.org audit[1]: SERVICE_START pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=hiya comm="systemd" exe="/usr/lib/systemd>
May 10 10:54:45 testvm1.each.org audit[1]: SERVICE_STOP pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=hiya comm="systemd" exe="/usr/lib/systemd/>
strains 1-46/46 (END)
If there have been a number of exercise on this time interval, you possibly can additional slender the ensuing knowledge stream utilizing a mixture of those choices:
[root@testvm1 ~]# journalctl --since="2020-05-10 10:54:35" --until="2020-05-10 10:55:00" -t "hello.sh"
-- Logs start at Tue 2020-05-05 18:11:49 EDT, finish at Sun 2020-05-10 11:10:41 EDT. --
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ###############################
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ######### Hello World! ########
May 10 10:54:45 testvm1.each.org hiya.sh[1380]: ###############################
[root@testvm1 ~]#
Your outcomes ought to be much like mine. You can see from this sequence of experiments that the service executed correctly.
Reboot—lastly
So far, you haven’t rebooted the host the place you put in your service. So try this now as a result of, in any case, this how-to is about operating a program at startup. First, it is advisable allow the service to launch in the course of the startup sequence:
[root@testvm1 ~]# systemctl allow hiya.service
Created symlink /and so on/systemd/system/multi-user.goal.desires/hiya.service → /and so on/systemd/system/hiya.service.
[root@testvm1 ~]#
Notice that the hyperlink was created within the /and so on/systemd/system/multi-user.goal.desires listing. This is as a result of the service unit file specifies that the service is “wanted” by the multi-user.goal.
Reboot, and make sure to watch the info stream in the course of the startup sequence to see the “Hello world” message. Wait … you didn’t see it? Well, neither did I. Although it glided by very quick, I did see systemd’s message that it was beginning the hiya.service.
Look on the journal for the reason that newest system boot. You can use the much less pager’s search software to search out “Hello” or “hello.” I pruned many strains of knowledge, however I left a number of the surrounding journal entries, so you may get a really feel for what the entries pertaining to your service seem like regionally:
[root@testvm1 ~]# journalctl -b
<snip>
May 10 10:37:49 testvm1.each.org systemd[1]: Listening on SSSD Kerberos Cache Manager responder socket.
May 10 10:37:49 testvm1.each.org systemd[1]: Reached goal Sockets.
May 10 10:37:49 testvm1.each.org systemd[1]: Reached goal Basic System.
May 10 10:37:49 testvm1.each.org systemd[1]: Starting Modem Manager...
May 10 10:37:49 testvm1.each.org systemd[1]: Starting Network Manager...
May 10 10:37:49 testvm1.each.org systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
May 10 10:37:49 testvm1.each.org systemd[1]: Condition verify resulted in Secure Boot DBX (blacklist) updater being skipped.
May 10 10:37:49 testvm1.each.org systemd[1]: Starting My hiya shell script...
May 10 10:37:49 testvm1.each.org systemd[1]: Starting IPv4 firewall with iptables...
May 10 10:37:49 testvm1.each.org systemd[1]: Started irqbalance daemon.
May 10 10:37:49 testvm1.each.org audit[1]: SERVICE_START pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=irqbalance comm="systemd" exe="/usr/lib/sy>"'
May 10 10:37:49 testvm1.each.org systemd[1]: Starting LSB: Init script for stay picture....
May 10 10:37:49 testvm1.each.org systemd[1]: Starting Hardware Monitoring Sensors...
<snip>
May 10 10:37:49 testvm1.each.org systemd[1]: Starting NTP consumer/server...
May 10 10:37:49 testvm1.each.org systemd[1]: Starting SYSV: Late init script for stay picture....
May 10 10:37:49 testvm1.each.org systemd[1]: Started SYSV: Late init script for stay picture..
May 10 10:37:49 testvm1.each.org audit[1]: SERVICE_START pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=livesys-late comm="systemd" exe="/usr/lib/>"'
May 10 10:37:49 testvm1.each.org hiya.sh[842]: ###############################
May 10 10:37:49 testvm1.each.org hiya.sh[842]: ######### Hello World! ########
May 10 10:37:49 testvm1.each.org hiya.sh[842]: ###############################
May 10 10:37:49 testvm1.each.org systemd[1]: hiya.service: Succeeded.
May 10 10:37:49 testvm1.each.org systemd[1]: Finished My hiya shell script.
May 10 10:37:49 testvm1.each.org audit[1]: SERVICE_START pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=hiya comm="systemd" exe="/usr/lib/systemd>"'
May 10 10:37:49 testvm1.each.org audit[1]: SERVICE_STOP pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=hiya comm="systemd" exe="/usr/lib/systemd/>
May 10 10:37:50 testvm1.each.org audit: BPF prog-id=28 op=LOAD
<snip>
You can see that systemd began the hiya.service unit, which ran the hiya.sh shell script with the output recorded within the journal. If you have been capable of catch it throughout boot, you’ll even have seen the systemd message indicating that it was beginning the script and one other message indicating that the service succeeded. By trying on the first systemd message within the knowledge stream above, you may see that systemd began your service very quickly after reaching the fundamental system goal.
But I wish to see the message displayed at startup as effectively. There is a approach to make that occur: Add the next line to the [Service] part of the hiya.service file:
StandardOutput=journal+consoleThe hiya.service file now seems to be like this:
# Simple service unit file to make use of for testing
# startup configurations with systemd.
# By David Both
# Licensed below GPL V2
#[Unit]
Description=My hiya shell script[Service]
Type=oneshot
ExecStart=/usr/native/bin/hiya.sh
StandardOutput=journal+console[Install]
WantedBy=multi-user.goal
After including this line, reboot the system, and watch the info stream because it scrolls up the show in the course of the boot course of. You ought to see the message in its little field. After the startup sequence completes, you may view the journal for the latest boot and find the entries in your new service.
Changing the sequence
Now that your service is working, you may take a look at the place it begins within the startup sequence and experiment with altering it. It is essential to do not forget that systemd’s intent is to begin as many providers and different unit varieties in parallel inside every of the main targets: fundamental.goal, multi-user.goal, and graphical.goal. You ought to have simply seen the journal entries for the latest boot, which ought to look much like my journal within the output above.
Notice that systemd began your take a look at service quickly after it reached the goal fundamental system. This is what you specified within the service unit file within the WantedBy line, so it’s right. Before you alter something, listing the contents of the /and so on/systemd/system/multi-user.goal.desires listing, and you will note a symbolic (tender) hyperlink to the service unit file. The [Install] part of the service unit file specifies which goal will begin the service, and operating the systemctl allow hiya.service command creates the hyperlink within the applicable “target wants” listing:
hiya.service -> /and so on/systemd/system/hiya.serviceCertain providers want to begin in the course of the fundamental.goal, and others don’t want to begin except the system is beginning the graphical.goal. The service on this experiment is not going to begin within the fundamental.goal—assume you don’t want it to begin till the graphical.goal. So change the WantedBy line:
WantedBy=graphical.goalBe certain to disable the hiya.service and re-enable it to delete the previous hyperlink and add the brand new one within the graphical.targets.desires listing. I’ve observed that if I neglect to disable the service earlier than altering the goal that wishes it, I can run the systemctl disable command, and the hyperlinks shall be faraway from each “target wants” directories. Then, I simply must re-enable the service and reboot.
One concern with beginning providers within the graphical.goal is that if the host boots to multi-user.goal, this service is not going to begin robotically. That could also be what you need if the service requires a GUI desktop interface, but it surely additionally is probably not what you need.
Look on the journal entries for the graphical.goal and the multi-user.goal utilizing the -o short-monotonic possibility that shows seconds after kernel startup with microsecond precision:
[root@testvm1 ~]# journalctl -b -o short-monotonicSome outcomes for multi-user.goal:
[ 17.264730] testvm1.each.org systemd[1]: Starting My hiya shell script...
[ 17.265561] testvm1.each.org systemd[1]: Starting IPv4 firewall with iptables...
<SNIP>
[ 19.478468] testvm1.each.org systemd[1]: Starting LSB: Init script for stay picture....
[ 19.507359] testvm1.each.org iptables.init[844]: iptables: Applying firewall guidelines: [ OK ]
[ 19.507835] testvm1.each.org hiya.sh[843]: ###############################
[ 19.507835] testvm1.each.org hiya.sh[843]: ######### Hello World! ########
[ 19.507835] testvm1.each.org hiya.sh[843]: ###############################
<SNIP>
[ 21.482481] testvm1.each.org systemd[1]: hiya.service: Succeeded.
[ 21.482550] testvm1.each.org smartd[856]: Opened configuration file /and so on/smartmontools/smartd.conf
[ 21.482605] testvm1.each.org systemd[1]: Finished My hiya shell script.
And some outcomes for graphical.goal:
[ 19.436815] testvm1.each.org systemd[1]: Starting My hiya shell script...
[ 19.437070] testvm1.each.org systemd[1]: Starting IPv4 firewall with iptables...
<SNIP>
[ 19.612614] testvm1.each.org hiya.sh[841]: ###############################
[ 19.612614] testvm1.each.org hiya.sh[841]: ######### Hello World! ########
[ 19.612614] testvm1.each.org hiya.sh[841]: ###############################
[ 19.629455] testvm1.each.org audit[1]: SERVICE_START pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=hiya comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 19.629569] testvm1.each.org audit[1]: SERVICE_STOP pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=hiya comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 19.629682] testvm1.each.org systemd[1]: hiya.service: Succeeded.
[ 19.629782] testvm1.each.org systemd[1]: Finished My hiya shell script.
Despite having the graphical.goal “want” within the unit file, the hiya.service unit runs about 19.5 or 19.6 seconds into startup. But hiya.service begins at about 17.24 seconds within the multi-user.goal and 19.43 seconds within the graphical goal.
What does this imply? Look on the /and so on/systemd/system/default.goal hyperlink. The contents of that file present that systemd first begins the default goal, graphical.goal, which then pulls within the multi-user.goal:
[root@testvm1 system]# cat default.goal
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is a part of systemd.
#
# systemd is free software program; you may redistribute it and/or modify it
# below the phrases of the GNU Lesser General Public License as printed by
# the Free Software Foundation; both model 2.1 of the License, or
# (at your possibility) any later model.[Unit]
Description=Graphical Interface
Documentation=man:systemd.particular(7)
Requires=multi-user.goal
Wants=display-manager.service
Conflicts=rescue.service rescue.goal
After=multi-user.goal rescue.service rescue.goal display-manager.service
AllowIsolate=sure
[root@testvm1 system]#
Whether it begins the service with the graphical.goal or the multi-user.goal, the hiya.service unit runs at about 19.5 or 19.6 seconds into startup. Based on this and the journal outcomes (particularly those utilizing the monotonic output), you recognize that each of those targets are beginning in parallel. Look at yet one more factor from the journal output:
[ 28.397330] testvm1.each.org systemd[1]: Reached goal Multi-User System.
[ 28.397431] testvm1.each.org systemd[1]: Reached goal Graphical Interface.
Both targets end at virtually the identical time. This is constant as a result of the graphical.goal pulls within the multi-user.goal and can’t end till the multi.person goal is reached, i.e., completed. But hiya.service finishes a lot sooner than this.
What all this implies is that these two targets begin up just about in parallel. If you discover the journal entries, you will note numerous targets and providers from every of these main targets beginning principally in parallel. It is evident that the multi-user.goal doesn’t want to finish earlier than the graphical.goal begins. Therefore, merely utilizing these main targets to sequence the startup doesn’t work very effectively, though it may be helpful for making certain that models are began solely when they’re wanted for the graphical.goal.
Before persevering with, revert the hiya.service unit file to WantedBy=multi-user.goal (if it isn’t already.)
Ensure a service begins after the community is operating
A typical startup sequence concern is making certain that a unit begins after the community is up and operating. The Freedesktop.org article Running services after the network is up says there isn’t any actual consensus on when a community is taken into account “up.” However, the article supplies three choices, and the one which meets the wants of a totally operational community is network-online.goal. Just remember that community.goal is used throughout shutdown somewhat than startup, so it is not going to do you any good when you’re making an attempt to sequence the startup.
Before making another modifications, make sure to look at the journal and confirm that the hiya.service unit begins effectively earlier than the community. You can search for the network-online.goal within the journal to verify.
Your service does not likely require the community service, however you need to use it as an avatar for one which does.
Because setting WantedBy=graphical.goal doesn’t be sure that the service shall be began after the community is up and operating, you want one other approach to make sure that it’s. Fortunately, there’s a simple approach to do that. Add the next two strains to the [Unit] part of the hiya.service unit file:
After=network-online.goal
Wants=network-online.goal
Both of those entries are required to make this work. Reboot the host and search for the situation of entries in your service within the journals:
[ 26.083121] testvm1.each.org NetworkManager[842]: <data> [1589227764.0293] machine (enp0s3): Activation: profitable, machine activated.
[ 26.083349] testvm1.each.org NetworkManager[842]: <data> [1589227764.0301] supervisor: NetworkManager state is now CONNECTED_GLOBAL
[ 26.085818] testvm1.each.org NetworkManager[842]: <data> [1589227764.0331] supervisor: startup full
[ 26.089911] testvm1.each.org systemd[1]: Finished Network Manager Wait Online.
[ 26.090254] testvm1.each.org systemd[1]: Reached goal Network is Online.
[ 26.090399] testvm1.each.org audit[1]: SERVICE_START pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=NetworkManager-wait-online comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? termina>"'
[ 26.091991] testvm1.each.org systemd[1]: Starting My hiya shell script...
[ 26.095864] testvm1.each.org sssd[be[implicit_files]][1007]: Starting up
[ 26.290539] testvm1.each.org systemd[1]: Condition verify resulted in Login and scanning of iSCSI units being skipped.
[ 26.291075] testvm1.each.org systemd[1]: Reached goal Remote File Systems (Pre).
[ 26.291154] testvm1.each.org systemd[1]: Reached goal Remote File Systems.
[ 26.292671] testvm1.each.org systemd[1]: Starting Notify NFS friends of a restart...
[ 26.294897] testvm1.each.org systemd[1]: iscsi.service: Unit can't be reloaded as a result of it's inactive.
[ 26.304682] testvm1.each.org hiya.sh[1010]: ###############################
[ 26.304682] testvm1.each.org hiya.sh[1010]: ######### Hello World! ########
[ 26.304682] testvm1.each.org hiya.sh[1010]: ###############################
[ 26.306569] testvm1.each.org audit[1]: SERVICE_START pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=hiya comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 26.306669] testvm1.each.org audit[1]: SERVICE_STOP pid=1 uid=zero auid=4294967295 ses=4294967295 msg='unit=hiya comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 26.306772] testvm1.each.org systemd[1]: hiya.service: Succeeded.
[ 26.306862] testvm1.each.org systemd[1]: Finished My hiya shell script.
[ 26.584966] testvm1.each.org sm-notify[1011]: Version 2.four.three beginning
This confirms that the hiya.service unit began after the network-online.goal. This is strictly what you need. You may have seen the “Hello World” message because it handed by throughout startup. Notice additionally that the timestamp is about six seconds later within the startup than it was earlier than.
The finest approach to outline the beginning sequence
This article explored Linux startup with systemd and unit recordsdata and journals in larger element and found what occurs when errors are launched into the service file. As a sysadmin, I discover that such a experimentation helps me perceive the behaviors of a program or service when it breaks, and breaking issues deliberately is an effective approach to study in a secure setting.
As the experiments on this article proved, simply including a service unit to both the multi-user.goal or the graphical.goal doesn’t outline its place within the begin sequence. It merely determines whether or not a unit begins as a part of a graphical setting or not. The actuality is that the startup targets multi-user.goal and graphical.goal—and all of their Wants and Requires—begin up just about in parallel. The finest approach to make sure that a unit begins in a selected order is to find out the unit it’s depending on and configure the brand new unit to “Want” and “After” the unit upon which it’s dependent.
Resources
There is an excessive amount of details about systemd out there on the web, however a lot is terse, obtuse, and even deceptive. In addition to the assets talked about on this article, the next webpages provide extra detailed and dependable details about systemd startup.
- The Fedora Project has a great, sensible guide to systemd. It has just about every little thing it is advisable know so as to configure, handle, and keep a Fedora laptop utilizing systemd.
- The Fedora Project additionally has a great cheat sheet that cross-references the previous SystemV instructions to comparable systemd ones.
- For detailed technical details about systemd and the explanations for creating it, take a look at Freedesktop.org‘s description of systemd.
- Linux.com‘s “More systemd fun” gives extra superior systemd information and tips.
There can be a sequence of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and first developer of systemd. These articles have been written between April 2010 and September 2011, however they’re simply as related now as they have been then. Much of every little thing else good that has been written about systemd and its ecosystem relies on these papers.
- Rethinking PID 1
- systemd for Administrators, Part I
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI