Ardika Sulistija: 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 systemctl reload , 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..."

2024-09-11T14:28:57Z

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 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 v..."

New page

==== 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'.

Systemd - Revision history