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
- (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?
- (trees view, ie include technical detail in description) Where specifically do each of these systems live on a typical Debian system?
- (forest) How do sym(or hard)links factor into tying all these systems together, and what happens if symlinks aren't managed properly?
- (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)?
- (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)
- (branch) How does one go about determining which level service handler to use?
- (branch) How do you determine which runlevel it should be using, as well as additional options related to the service's successful execution
- (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.
- (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.
- (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
systemctl enable lidarr.service
Failed to enable unit: Unit /run/systemd/generator.late/lidarr.service is transient or generated.
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
systemd enablebecause 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-generatorinstead of the
can't do, won't tell you whything it usually does.