Open In App

Systemd vs Init Cheatsheet for Linux

Last Updated : 28 Mar, 2022
Comments
Improve
Suggest changes
Like Article
Like
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 serviceservice dummy startsystemctl start dummy.service
Stop a serviceservice dummy stopsystemctl stop dummy.service
Restart a serviceservice dummy restartsystemctl restart dummy.service
Reload a service service dummy reloadsystemctl reload dummy.service
Service status service dummy statussystemctl status dummy.service
Restart a service if already runningservice dummy condrestartsystemctl condrestart dummy.service
Enable service at startupchkconfig dummy on systemctl enable dummy.service
Disable service at startupchkconfig dummy offsystemctl disable dummy.service
Check if a service is enabled at startupchkconfig dummysystemctl is-enabled dummy.service
Create a new service file or modify configurationchkconfig dummy --addsystemctl daemon-reload

Runlevels commands:

Comments

SysVinit

Systemd

System halt 0runlevel0.target, poweroff.target
Single user mode1, s, singlerunlevel1.target, rescue.target
Multi user2runlevel2.target, multi-user.target
Multi user with Network3runlevel3.target, multi-user.target
Experimental 4runlevel4.target, multi-user.target
Multi user, with network, graphical mode5runlevel5.target, graphical.target
Reboot6runlevel6.target, reboot.target
Emergency Shellemergencyemergency.target
Change to multi user runlevel/targettelinit 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 runlevelrunlevelsystemctl 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 hostsystemctl dummy.service start -H user@host
Check boot timesystemd-analyze or systemd-analyze time
Kill all processes related to a servicesystemctl kill dummy
Get logs for events for todayjournalctl --since=today
Hostname and other host related informationhostnamectl
Date and time of system with timezone and other informationtimedatectl

Article Tags :

Similar Reads