Open In App

Systemd vs Init Cheatsheet for Linux

Last Updated : 28 Mar, 2022
Improve
Improve
Like Article
Like
Save
Share
Report

Systemd is the new init framework, beginning with Fedora and presently embraced in numerous circulations like RedHat, Suse, and Centos. All things considered, the vast majority of us have been utilizing conventional SysV init scripts typically living in/and so on/rc.d/init.d/. These contents conjure a daemon parallel which will then, at that point, fork a foundation cycle. Despite the fact that shell scripts are entirely adaptable, undertakings like administering processes and parallelized execution requesting are challenging to carry out. With the presentation of systemd’s recent fad daemons, it is more straightforward to oversee and control them at runtime and it works on their execution.

The systemctl order is an awesome drive by the systemd group. It shows more point-by-point blunder messages and furthermore runtime mistakes of administrations including fire up blunders. systemd has presented another term called cgroups (control gatherings) which is essentially gatherings of interaction that can be sorted out in order. With the first init framework, figuring out which cycle does what and who it has a place with turns out to be progressively troublesome. With systemd, when cycles generate different cycles these kids are naturally made individuals from the guardians cgroup subsequently staying away from disarrays about legacy.

Service-Related Commands :

Comments

SysVinit

Systemd

Start a service service dummy start systemctl start dummy.service
Stop a service service dummy stop systemctl stop dummy.service
Restart a service service dummy restart systemctl restart dummy.service
Reload a service  service dummy reload systemctl reload dummy.service
Service status  service dummy status systemctl status dummy.service
Restart a service if already running service dummy condrestart systemctl condrestart dummy.service
Enable service at startup chkconfig dummy on  systemctl enable dummy.service
Disable service at startup chkconfig dummy off systemctl disable dummy.service
Check if a service is enabled at startup chkconfig dummy systemctl is-enabled dummy.service
Create a new service file or modify configuration chkconfig dummy –add systemctl daemon-reload

Runlevels commands:

Comments

SysVinit

Systemd

System halt  0 runlevel0.target, poweroff.target
Single user mode 1, s, single runlevel1.target, rescue.target
Multi user 2 runlevel2.target, multi-user.target
Multi user with Network 3 runlevel3.target, multi-user.target
Experimental  4 runlevel4.target, multi-user.target
Multi user, with network, graphical mode 5 runlevel5.target, graphical.target
Reboot 6 runlevel6.target, reboot.target
Emergency Shell emergency emergency.target
Change to multi user runlevel/target telinit 3

systemctl isolate multi-user.target

(OR systemctl isolate runlevel3.

target)

Set multi-user target on next boot

sed s/^id:.*:initdefault:/

id:3:initdefault:/ 

ln -sf /lib/systemd/system/multiuser.target /etc/systemd/system/

default.target

Check current runlevel runlevel systemctl get-default
Change default runlevel

sed s/^id:.*:initdefault:/

id:3:initdefault:/ 

systemctl set-default multi-user.target

Systemd New Commands :

Comments

Systemd

Execute a systemd command on remote host systemctl dummy.service start -H user@host
Check boot time systemd-analyze or systemd-analyze time
Kill all processes related to a service systemctl kill dummy
Get logs for events for today journalctl –since=today
Hostname and other host related information hostnamectl
Date and time of system with timezone and other information timedatectl

Like Article
Suggest improvement
Share your thoughts in the comments

Similar Reads