We earn commission when you buy through affiliate links.
This does not influence our reviews or recommendations.Learn more.
Wondering how to manage services in the background or on boot?
The mechanism for managing and starting processes on boot has been changed.
What is systemd?
Since every process in Linux is transparently visible, lets see wheresystemdis lurking.
On my system, I get the following:
I bet you noticed it instantly.
the first process in the listing was launched as the userroot, and has the pid 1.
Sure enough, this was the first process that the system launched upon boot.
A note on the name, though.
The name is indeedsystemdand not System D or anything else.
The d stands for daemon, a standard Linux process that works (lurks?)
in the background and isnt attached to any terminal session.
Why RHEL switched to systemd?
Why did RHEL take this decision?
Well, there are very good reasons for this, so lets take a quick look.
Parallel service initialization
Unlikes the SysVinitprogram,systemdis capable of launching services in parallel.
Theinitprogram, by contrast, launches them one by one.
It is able to detect live changes in hardware and terminate/launch services as needed.
Some can argue that its unnecessary, but to many, anything that reduces cognitive burden is most welcome.
Deferred service launch
systemdmakes boot times shorter as its able to defer service launch to when its actually needed.
A simple example is internet file system-related services.
If theres no networked disk available, it doesnt make sense to have a service up and running.
Automatic restart
If a service crashes,systemdcan detect that and attempt to restart it.
Anyway,systemdmakes the life of a sysadmin easier here.
systemd in RHEL7 What changes for Sysadmins?
If you have a nagging feeling thatsystemdisnt going to be all bells and whistles, youre right.
There are a few significant incompatibilities that can catch RHEL sysadmin by surprise.
Lets take a quick look.
Limited runlevel support
systemdhas a pretty shabby recognition of and support for runlevels.
Not all the runlevels are supported, and for some targets there might even be none.
All in all, Red Hat advises us to not use (!)
No custom commands
This ones going to hurt.
One big plus with SysV was the ability to define custom commands to provide better functionality for managing processes.
Withsystemd, theres no such option and youre stuck withstart,stop,status,restart, etc.
The challenge, however, is thatsystemdcannot deal with processes not launched by it.
Further, its not possible for a user to interact with a process started bysystemd.
All output goes to/dev/null, effectively putting a stop on any hopes you mightve had of capturing output.
No context
Unlikeinitservices, those launched bysystemddo not inherit any environment from any users in the system.
How to Start Service Automatically When Down?
Heres a pretty common use case in deployments.
We need to daemonize a program in a language that doesnt have long-running processes: PHP!
and the script is placed at/home/ankush/chat_server/index.php.
Anyway, enough on websockets; lets see how well go about daemonizing this script viasystemd.
Allsystemdservices reside in /etc/systemd/system, so lets create a file there to describe our websocket server script.
Assuming you are logged in as a root user.
and then the following is needed.
More option for Restart logic
In the above example, Ive configuredRestart=on-abortbut thats not the only option.
There are more and choose based on the requirement.
power cycle your server and you should see service starts on the boot.
Im massively invested in Upstart.
I understand you trust me, your case is the norm rather than the exception.
RHEL has been using Upstart for so long that the switch almost feels like a betrayal.
But hey, systems keep changing, and we shouldnt squabble over trifles.
Interested in learning more about Linux Administration and Troubleshooting?
Check out thisonline course.
