[systemd-devel] Runtime symlinks replaced by hard files, systemctl enable no longer works

[Joey Dodson]

We do back up some system settings, but I'm fairly sure it doesn't include
/etc/systemd/system whatsoever. This is a multi user system though, so I'll
have to check with others if they have any idea. I guess you're saying this
is not something that could have come from systemd or the OS?

On Tue, Jun 4, 2024 at 3:23 PM Cristian Rodríguez <crrodriguez at opensuse.org>
wrote:

> On Tue, Jun 4, 2024 at 5:03 PM Joey Dodson <jdodsonelements at gmail.com>
> wrote:
> >
> > Hello list!
> >
> >
> >
> > Thanks in advance for any help or thoughts!
> >
> >
> >
> > Background:
> >
> >
> >
> > I have a system where many ‘/etc/systemd/system’ symlink paths got
> replaced by files. Therefore, ‘systemctl enable’ no longer works for a
> majority of services. Though somehow there are some services that appear to
> not have been affected. This happened for everything in
> ‘/etc/systemd/system/multi-user.target.wants’ and it seems all/many of the
> ‘*.target.wants’ directories.
> >
> >
> >
> > If I delete the hard files, then I can use ‘systemctl enable’ for that
> service, but it’s not so simple. Many services have dependencies and
> aliases and it will throw the following error message:
> >
> >
> >
> > ‘Failed to execute operation: Invalid argument’
> >
> >
> >
> > And it may create the symlink for the main unit file, but the
> dependencies and aliases have still failed. Therefore it’s going to leave
> the system in a broken state unless I can get everything.
> >
> >
> >
> > Further context:
> >
> >
> > Last time the server was rebooted, it was unable to boot into any
> kernel, including our rescue kernel. Only emergency mode was possible
> through editing the grub boot options. Somehow the default target was no
> longer set to ‘multi-user.target’, but we have no logical explanation for
> how that could have happened.
> >
> >
> >
> >
> >
> > Questions:
> >
> > Has anyone seen something like this before? How could this have
> happened? We suspected rsync/scp from another machine, but since there are
> some symlinks unaffected I think that’s less likely. Is there any mechanism
> of systemd that could have caused it?
> > Systemd has commands to list where the original unit files are located,
> but I need the opposite. Is it possible to list the paths where symlinks
> will go when using ‘systemctl enable’? The error message above is not
> descriptive and according to search results, it could indicate that a
> service is masked, a unit file has extra spaces, symlinks can’t be created
> or any number of things. Without knowing the path for symlinks, I don't
> know which files to delete to get it working again.
> > I saw there is a ‘-force’ option for ‘systemctl enable’, but it seems
> that it will only overwrite symlinks, not hard files. Is there another way
> to overwrite files in the intended symlink path?
> > Is there anything I’m missing here? I’ve never seen this before today
> and am pretty stuck with how this could have happened and how to resolve it
> in a thorough/holistic way.
> >
>
>
> Well..the symlinks where restored from an archive that did not support
> symlinks?   assuming you want all those services enabled again you
> could write a shell script that replaces hard files to symlinks..
> It will happen again if you do not determine where that came from
> though. whatever did that needs a blowtorch.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240604/a3ba971d/attachment.htm>