Unit incus.socket not found

Bonjour,

Would anyone know how to fix the following error:

$ sudo systemctl status incus.socket
Unit incus.socket could not be found.

$ sudo systemctl start incus.service
Failed to start incus.service: Unit incus.socket not found.

I upgraded a ubuntu 20.04 lxd server 22.04, to see if I could download an image, but it was a no go. Therefore, I installed the incus package from the Zabbly repo.

Without doing an incus init, I checked the info command for both incus and lxd and they both worked. I then ran the migration tool lxd-to-incus, which seemed to work.

At this point I tried to install a container, but I again encountered an error saying it was not possible to locate the image. I tried a debian and ubuntu image but no luck.

After quick browse of this website I found a post, with a seemingly similar issue, that was suggesting the deletion of the /var/cache/incus directory contents.

Not sure if that is the cause of my current problems, but I took and late night gamble to try and get things running and I wiped the contents of this directory (the gamble failed).

Any thoughts would be appreciated!

Incus came to life again after a simple:
$ sudo systemctl enable incus.service

I still could not launch a container though:

$ sudo incus launch images:ubuntu/22.04 first
Launching first
Error: Failed instance creation: Failed to run: /opt/incus/bin/incusd forkstart first /var/lib/incus/containers /run/incus/first/lxc.conf: exit status 1

After another site search I modified the following files /etc/subuid and /etc/subgid to have only one root entry at the end of each files as follows:

root:1000000:1000000000

After restarting the incus service my containers are running again.

linuxcontainers.org came good again. :ok_hand:

1 Like

Hi!

The first issue, the one that systemctl could not find incus.socket I think can happen if you do not initialize Incus. If you do not initialize Incus or perform the migration, then there are no services to run.

After you perform the migration, then you might get into the /etc/subuid and /etc/subgid problem; they may have conflicting invalid values that should be cleaned up. It’s great that you found the older post and fixed it.

Note that you do not need to run sudo with the incus commands. You can add your non-root user into the incus-admin Unix group (same as old lxd group membership) or incus Unix group (more restrictive).

Hello Simos,

I have your followed a few of your howto / blogs posts before. Thanks for sharing your knowledge. I probably wouldn’t have got LXD running without your LXD networking posts.

Last night I thought I had solved this, but I booted the server today and it is not quite fixed yet!

$ sudo adduser user1 incus-admin
$ incus list
Error: Unable to read the configuration file: open /home/user1/.config/incus/config.yml: permission denied
$ sudo incus list
[sudo] password for user1: 
Error: The incus daemon doesn't appear to be started (socket path: /var/lib/incus/unix.socket)
$ sudo systemctl enable incus.service
Failed to enable auxiliary unit incus-startup.service, ignoring.
Failed to enable auxiliary unit incus.socket, ignoring.
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.
$ sudo systemctl start incus.service
$ sudo incus list
+----------+---------+-----------------------+------+-----------+-----------+
|   NAME   |  STATE  |         IPV4          | IPV6 |   TYPE    | SNAPSHOTS |
+----------+---------+-----------------------+------+-----------+-----------+

The first error has been fixed. .config/ was owned by root instead of user1

Getting the service to start at boot looks like the last one for me to resolve.

Thanks! I am in the process of rewriting the old posts so that they cover Incus.
The old ones will be gone, one by one. For example, like this, How to run a Windows virtual machine on LXD on Linux – Mi blog lah!

On your question, see this post, Migrating to Incus from LXD – Mi blog lah!

It talks about how to add your non-root account to the incus-admin group. You would use usermod to add an existing non-root account to the incus-admin group. Once you add your non-root account to the incus-admin, you need to logout and log in again so that the system. It’s a Unix/Linux thing.

The purpose of adding your non-root account to the incus-admin Unix group is that you avoid using sudo with the incus commands. Also, you avoid issues like bad permissions like for the /home/user1/.config/incus/config.yml file.

When you are using incus with the incus-admin Unix group, there are only two situation where you need to use sudo, when you initialize Incus or when you perform the migration. The rest are without sudo.

Having found the following post I have discovered why Incus will not start at boot:

https://discuss.linuxcontainers.org/t/incus-snapper-and-btrfs-subvolumes/18476/21

I have /opt in a separate logical volume and it has given me the same issue as Victor, where Incus will not start at boot.

1 Like

Thanks for this. I added your reply in my bookmarks. Yes, Discourse supports bookmarks.