1

I'm not asking about the files in the filesystem that configures the services, but about the internal database of systemctl itself, or perhaps the files that systemctl creates.

Questions:

  • How does systemctl scheduler work?
  • Where is its data about running services stored? ***Unfortunately, the post was corrected externally with the loss of content and meaning. You can reformulate it as you like, but it is important for me to understand where the service records are stored so that I can delete one specific broken record. That is, to repair the host without reinstalling the operating system and services. I do not know how to do this with using systemctl utility calls.

Note: This question is a refinement of the question how totally remove unexistent service from systemd/systemctl?

We catch a lame cockroach, burn it and bury the ashes. but he, his ghost, continues to nibble cookies. Task: to catch a ghost.

3 Answers3

2

There is no internal database. All state about running or failed services is only kept in memory, as part of the main systemd process.

On every startup, systemd starts in a clean slate with no units, then loads one "initial" unit (typically default.target) and builds a dependency tree from it, loading other units only if they are specified as a dependency of a previously loaded unit.

(Most of those units come from the usual /etc/systemd and /usr/lib/systemd locations. Some units are found in /run/systemd, which is in-memory – they are re-generated on every startup and every daemon-reload from sources such as fstab or init.d.)

(Additionally, on every startup, systemd creates in-memory virtual .device units according to kernel "device detected" uevents, which may have dependencies added by an udev rule – e.g. .device units corresponding to Bluetooth host controllers get a dependency on bluetooth.target.)

grawity
  • 501,077
1

The post "What is Systemctl? An In-Depth Overview" gives a good overview of what it for a simple and concise enough understanding. I've referenced and quoted the part of the post below that I believe helps break it down in simple terms along with a screen shot visual.

The simple explanation is that the systemctl command is a utility used to interact with and configure systemd. Systemd is compromised of system management libraries, utilities, and daemons that function as a successor to the System V init daemon that is started at system boot up and continues to run until the system is shut down.

What is Systemctl?

The systemctl command is a utility which is responsible for examining and controlling the systemd system and service manager. It is a collection of system management libraries, utilities and daemons which function as a successor to the System V init daemon. The new systemctl commands have proven quite useful in managing a servers services. It provides detailed information about specific systemd services, and others that have server-wide utilization.

Keep in mind that most of the systemctl commands will not provide any output if they have been successful. However, if the systemctl command has failed to complete the task, you will get an error message stating that it failed.

enter image description here

What is a Service?

In the systemd utility, a service is referred to as a unit. A unit is any resource that the system knows how to act on and administrate. A unit is the principal object that the systemd tools know how to address. These assets are defined in a configuration file called a unit file.

Source

Other Relevant Resources

1

This is a not complete list of places where units can be stored *.service, service parts and symlink files: How to remove systemd services

Is there some more:

/usr/bin/
/home/{username}/.config/

And somewhere else there may be remnants of units or symlinks

In my case, the global search in files by content helped:

grep --include=\*.service -rnw '/' -e "conten-search-template"

Where conten-search-template is a name of the service executable file or wildcard.