systemd failing enable with "service is transient or generated". What's wrong with this configuration?

Question

In General

I've been scouring the web looking for actually helpful documentation about systemd and this error, but the majority of it has been troubleshooting niche cases or goes into such extreme detail that the information is useless. I'm trying to set up 1 simple, custom service. It should be a simple matter of registering then enabling the service, but apparently systemd makes that more complicated than it needs to be.

This has been a thorn in my side for years, and I'm finally at a point where I'm ready to abandon any operating system hosting systemd in favor of something that isn't completely insane in its implementation and will run as expected for a simple init script.

Out of general

Before I completely give up on systemd, I want to give it one more shot. What I want to know in detail (but explained in a scope suitable for a junior systems developer) is

1. (forest view, ie toplevel explanation desired without technical detail) What types of services does systemd manage, and how (chronologically) did systemd expand to manage them?
2. (trees view, ie include technical detail in description) Where specifically do each of these systems live on a typical Debian system?
3. (forest) How do sym(or hard)links factor into tying all these systems together, and what happens if symlinks aren't managed properly?
4. (branch view, as much nitty gritty as possible, don't hold back) How does systemd manage running services (ie: what kind of workflow does it follow)?
5. (trees) Similar to the previous question, are these different types of services started in tiers? (I know there's dependencies and runlevels .. but how are these assigned to different system levels .. ie /opt software vs kernel level)
6. (branch) How does one go about determining which level service handler to use?
7. (branch) How do you determine which runlevel it should be using, as well as additional options related to the service's successful execution
8. (branch) Where can individual (working) examples be found or used as a template? I would think there would be some sort of skeleton folder for different kinds of services, but I've yet to find it.
9. (branch) If a new service isn't create correctly, what steps can be taken to remove the faulty service and start clean? Many of my attempts to start clean after a failed service creation clearly have been stopped by remnant symlinks and other vestigial files left behind by the initial failed attempt, and despite using "find" and "ls" (and yes, executing sync and echo 3 > cache) to categorically search and destroy any file even remotely related to the service, the service still fails.
10. (trees) To make life easier, a quick way to find any symlinks that might be gunking up system.d's process (which shows absolute path)

Bought a little more general

My specific error

1. systemctl enable lidarr.service

   Failed to enable unit: Unit /run/systemd/generator.late/lidarr.service is transient or generated.

2. cat of /etc/init.d/lidarr.service .. meow

3. ls of /etc/init.d/

4. ls of /etc/systemd/system, part 1

5. ls of /etc/systemd/system, part 2

6. ls of /etc/systemd/system, part 3

Things I've tried to do to fix it

• Daemon reload
• Delete all traces of the failed service
• Flush the cache
• Remove any symlinks (that I could find)
• Chmod +x the service
• Manually create a symlink where others were created, pointing to the service (this has worked sporadically in the past .. again, systemd has too many handlers floating around that behavior isn't predictable)
• Cry, drink somewhat heavily
• Plead, bargain
• A full system reinstall .. yes, the nuclear option

Pretty please, with sugar on top .. make this not be so confusing

Solution

I suspect the file you placed in /etc/init.d/ was supposed to go to /etc/systemd/system/.

Move the systemd .service file away from the location meant for System V style init scripts and to a systemd unit directory, refresh available units & confirm you then are using the intended unit file:

# mv /etc/init.d/lidarr.service ~/lidarr.service.bak
# cp lidarr.service /etc/systemd/system/

# systemctl daemon-reload
# systemctl cat lidarr.service

(output should mention (only) your unit path at /etc/systemd/system/lidarr.service)

# systemctl start lidarr.service
# journalctl -e -u lidarr.service

The output may still contain other problems you might have follow-up questions about, but at least now you should be using your unit file.

Key points for understanding the problem you ran into:

1. systemd units are far more complex & abstracted than simple sysv-style init scripts. systemd ships an automation to generate (and cleanup when no longer needed) suitable units files dynamically for compatibility. However, for any given unit name you can only use either generators or manage the unit file directly.
2. If you write the systemd unit yourself (typically strongly preferred over automatic generation) the systemd unit file goes to a path such as /etc/systemd/system/ - not mixed with the executable init scripts in /etc/init.d/ traditionally used by sysv-style init.

The manual for systemctl tells us the following about the generated status:

The unit file was generated dynamically via a generator tool. See systemd.generator(7). Generated unit files may not be enabled, they are enabled implicitly by their generator.

So your error message means that one of the methods through which systemd can automatically generate unit files for you is in use, preventing you from using the one you wrote yourself.

Comments

[anx]

Oh and if you are more capable to restrain your disgust for that software than I am, please do file a respectfully written bug/RFE against systemd enable because it really should always print This service cannot be manually enabled because it is managed by the systemd generator at /lib/systemd/system-generators/systemd-sysv-generator instead of the can't do, won't tell you why thing it usually does.