Ton of random units "could not be found"

[Lennart Poettering]

On Fr, 15.12.23 22:17, chandler (scar at riseup.net) wrote:

> Hi all,
>
>     When I run `systemctl status --all` I see a ton of "Unit X could not
> be found" where X = an item from the list below.  How did this mess
> happen and how to clean it up?  None of these units represent things the
> system is using, for the most part.

This is not an issue. As Andrei already answered this just tells you
that some services have ordering deps against other units which aren't
installed, which is entirely fine. It's just metainfo that if you
install some packages in combination the right order is applied.

There's a reason why these entries are generally not shown. Except you
used "--all", which literally means "Hey, please also show me
*everything* you have heard about". Just drop the "--all" from your
command line.

>     Some units appear to be remnants left behind in /etc/systemd, for
> example /etc/systemd/system/ntp.service is a symlink pointing to
> non-existent /lib/systemd/system/ntpsec.service.  I can delete
> /etc/systemd/system/ntp.service and after `systemctl daemon-reload` it's
> now gone from the list below.

That smells like a packaging bug, you removed some package and it
forgot to invoke "systemctl disable" from it's pakaging uninstall
scripts first. File a bug against yout distro.

>     Other items have different situations, like tmp.mount exists at
> /usr/share/systemd/tmp.mount but isn't an enabled unit or anything, if I
> try to enable or unmask it I'm just told "Unit tmp.mount could not be
> found." or "Unit file tmp.mount does not exist."

/usr/share/systemd/ is not a directory systemd ever looks into for
unit files. If debian packaged something there, this smells like a
bug. Please report to your distro.

Lennart

--
Lennart Poettering, Berlin