Systemd

From DikapediaV2
Revision as of 14:28, 11 September 2024 by Ardika Sulistija (talk | contribs) (Created page with "==== Making Changes to Systemd unit files/configuration ==== ---- When you have made changes to the unit file of a service on the filesystem. In order for the service to use that new configuration, we need to tell the service to reload its configuration file. So run <b>systemctl reload <service></b>, to tell the service to dump the current configuration you are using and RELOAD its configuration from the filesystem into memory, and now it would use that newly modified v...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Making Changes to Systemd unit files/configuration


When you have made changes to the unit file of a service on the filesystem. In order for the service to use that new configuration, we need to tell the service to reload its configuration file. So run systemctl reload <service>, to tell the service to dump the current configuration you are using and RELOAD its configuration from the filesystem into memory, and now it would use that newly modified version. Since the service was never actually terminated or stopped, it retains the same main PID.

When you do systemctl restart <service>, you terminate the service and stop it, it would dump its configuration which is in memory. Then the restart action would result in the service start up again. It will load its configuration file from the file system, load up into and now it would use the version of the configuration file that is in memory. And because the service was terminated, and restarted, the service main PID will change.


My recipe for service obliteration (be careful with the rm statements!)


$ systemctl stop [servicename]
$ systemctl disable [servicename]
$ rm /etc/systemd/system/[servicename]
$ rm /etc/systemd/system/[servicename] # and symlinks that might be related
$ rm /usr/lib/systemd/system/[servicename] 
$ rm /usr/lib/systemd/system/[servicename] # and symlinks that might be related
$ systemctl daemon-reload
$ systemctl reset-failed
  • Services under /etc/systemd/system/ or /etc/systemd/system/multi-user.target.wants/ are enabled

https://superuser.com/questions/513159/how-to-remove-systemd-services


Per my customer's issue, we fixed it by: Removing the auditd.service from /usr/lib/systemd/system so you wont be able to start the service upon bootup.

To be able to start the service again you have to run: "systemctl daemon-reload” in addition to having the <>.service file in that directory

$ sudo systemctl start firewalld.service 
Failed to start firewalld.service: Unit not found.

$ sudo systemctl daemon-reload
$ sudo systemctl start firewalld.service

Disabling a Service


To disable it, you call systemctl disable <service>. Without arguments, systemctl displays the current state, which is obviously not possible in a chroot.

Alternatively, you can also go to /etc/systemd/system/ and remove the symlink to your service (probably in the multi-user.target.wants folder).

If it is a service that is enabled by default, you need to create a symlink (named <service>.service) to /dev/null to disable it. Where the symlink needs to be depends on where in /lib/systemd/system the service is enabled.


How to list all running services


systemctl list-units --type=service --state=running
UNIT                       LOAD   ACTIVE SUB     DESCRIPTION
auditd.service             loaded active running Security Auditing Service
chronyd.service            loaded active running NTP client/server
crond.service              loaded active running Command Scheduler
dbus.service               loaded active running D-Bus System Message Bus
getty@tty1.service         loaded active running Getty on tty1
NetworkManager.service     loaded active running Network Manager
polkit.service             loaded active running Authorization Manager
rhsmcertd.service          loaded active running Enable periodic update of entitlement certificates.
rsyslog.service            loaded active running System Logging Service
serial-getty@ttyS0.service loaded active running Serial Getty on ttyS0
sshd.service               loaded active running OpenSSH server daemon
sssd.service               loaded active running System Security Services Daemon
systemd-journald.service   loaded active running Journal Service
systemd-logind.service     loaded active running Login Service
systemd-udevd.service      loaded active running udev Kernel Device Manager
tuned.service              loaded active running Dynamic System Tuning Daemon 
user@1000.service          loaded active running User Manager for UID 1000

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

17 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

A Unit is an aspect of the system that systemd manages. There are various types of units. We have service units that are used for daemons. We have socket units for TCP ports. We have path units to manage files and directories. Target units as well which are groups of other units.

Every unit is represented by a unit file that has its configuration.

systemctl list-units --type=socket
UNIT                            LOAD   ACTIVE SUB       DESCRIPTION
dbus.socket                     loaded active running   D-Bus System Message Bus Socket
sssd-kcm.socket                 loaded active listening SSSD Kerberos Cache Manager responder socket
systemd-coredump.socket         loaded active listening Process Core Dump Socket
systemd-initctl.socket          loaded active listening initctl Compatibility Named Pipe
systemd-journald-dev-log.socket loaded active running   Journal Socket (/dev/log)
systemd-journald.socket         loaded active running   Journal Socket
systemd-udevd-control.socket    loaded active running   udev Control Socket
systemd-udevd-kernel.socket     loaded active running   udev Kernel Socket

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

8 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.