0

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
  • 21
  • 6
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking. – Community Oct 30 '22 at 05:18
  • Where are you getting the log info for the job attempting to start? You've stripped out so much stuff from that log entry that there's no service name or daemon name associated with it. – user10489 Oct 30 '22 at 05:55
  • A service that does not exist cannot possibly be started. There is no secret storage location or anything. There are only files. Please give the _full_ output of `systemctl status yourservice`, with the _exact_ original service name. – Daniel B Oct 31 '22 at 14:03
  • You stubbornly refuse to believe and I don't know how to explain it to you. It's clean in the file system. In all folders, all files have been deleted. status: "service could not be found.". I ask where this is stored: "Scheduled restart job, restart counter is at 2." – user1787509 Nov 01 '22 at 02:37
  • I think you need to list out all your jobs that are scheduled with the systemctl command accordingly, and then figure out which job is pointing to an executable/binary that does not exist. Check the journal log or journalctl, etc. to see if it is screaming to help you identify which job systemctl manages which it is screaming about. Otherwise, repair your Linux system or look up how to repair systemd, systemctl is just a command of the systemd system. If systemd is hosed, see if you can repair it to fix systemctl. Otherwise narrow down or dig in logs to find more verbose detail of issues. – Vomit IT - Chunky Mess Style Nov 01 '22 at 04:27
  • Unit www.service could not be found. by exact and executable name. Not finded in file system. updates, reboot, reload all known and systemctl methods not repair it. They suggest reinstalling debian. That is, it is such a popular system that no one knows how to use it. – user1787509 Nov 01 '22 at 06:37

1 Answers1

1

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.

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966