2

No files, no symlinks, service does not exist. systemctl unit not listed, unit-file not listed.

systemctl daemon-reload
systemctl reset-failed
systemctl reboot
0 loaded units listed.

log entry cycle:

Scheduled restart job, restart counter is at 2.
Failed to locate executable
Failed at step EXEC spawning
Main process exited, code=exited, status=203/EXEC
Failed with result 'exit-code'.

Where is it stored, how to remove it?

"tell exactly what you're asking" - It is disabled, stopped and deleted, but there are attempts to start it.

user1787509
  • 41

1 Answers1

2

As there is no persistent cache of units that would carry state over across reboots, the only way for a .service unit to reach the point of attempting to exec something is if the unit existed during the current boot, and likewise its original start job must have been issued during the current boot.

systemctl show -p FragmentPath will show the location of the files that the unit was loaded from. There could be several cases:

  • It exists in /etc/systemd/system or (/usr)/lib/systemd/system as a regular file.

  • It has previously existed in /etc/systemd/system or (/usr)/lib/systemd/system during the current boot (at the moment the start request was issued), but has been deleted since – e.g. the package was uninstalled while the service unit remains running.

  • It exists in /run/systemd/system, as the output of some other service that would create units on the fly during system boot.

  • It exists in /run/systemd/generator, as the output of a systemd "unit generator" that runs during each boot and daemon-reload. For example, SysV /etc/init.d scripts are automatically wrapped in systemd units by a generator.

  • It is a "transient unit" created through a D-Bus call, such as systemd-run.

grawity
  • 501,077