But none of them are able to start, journalctl doesn’t reveal much information and I don’t see any daemon logs in /var/log/incus to track down why it’s failing.
sudo systemctl status incus
× incus.service - Incus - Daemon
Loaded: loaded (/usr/lib/systemd/system/incus.service; indirect; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: failed (Result: exit-code) since Mon 2024-07-15 12:37:13 EEST; 12min ago
TriggeredBy: ● incus.socket
Docs: man:incusd(1)
Process: 10029 ExecStart=/usr/lib/incus/incusd --group incus-admin (code=exited, status=203/EXEC)
Process: 10030 ExecStartPost=/usr/lib/incus/incusd waitready --timeout=600 (code=exited, status=203/EXEC)
Main PID: 10029 (code=exited, status=203/EXEC)
CPU: 4ms
jūl 15 12:37:13 pc-158 systemd[1]: incus.service: Scheduled restart job, restart counter is at 5.
jūl 15 12:37:13 pc-158 systemd[1]: incus.service: Start request repeated too quickly.
jūl 15 12:37:13 pc-158 systemd[1]: incus.service: Failed with result 'exit-code'.
jūl 15 12:37:13 pc-158 systemd[1]: Failed to start incus.service - Incus - Daemon.
jūl 15 12:37:20 pc-158 systemd[1]: incus.service: Start request repeated too quickly.
jūl 15 12:37:20 pc-158 systemd[1]: incus.service: Failed with result 'exit-code'.
jūl 15 12:37:20 pc-158 systemd[1]: Failed to start incus.service - Incus - Daemon.
Perhaps completely unrelated but incus-workaround.service fails because /usr/lib/incus is not present as per ConditionPathExists=/usr/lib/incus
sudo systemctl status incus-workaround -l
○ incus-workaround.service - Workaround swtpm not having the correct label
Loaded: loaded (/usr/lib/systemd/system/incus-workaround.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: inactive (dead)
Condition: start condition unmet at Mon 2024-07-15 12:40:32 EEST; 13min ago
└─ ConditionPathExists=/usr/lib/incus was not met
jūl 15 12:35:30 pc-158 systemd[1]: incus-workaround.service - Workaround swtpm not having the correct label was skipped because of an unmet condition check (ConditionPathExists=/usr/lib/incus).
jūl 15 12:40:32 pc-158 systemd[1]: incus-workaround.service - Workaround swtpm not having the correct label was skipped because of an unmet condition check (ConditionPathExists=/usr/lib/incus).
Seems like a bug, as a workaround, starting the daemon manually works: sudo INCUS_EDK2_PATH=/usr/share/edk2/ovmf /usr/libexec/incus/incusd --group incus-admin
I’m seeing the same thing, so it’s not just you. Thanks for the workaround, hopefully this is temporary. The workaround isn’t great; incus commands work, but the service and socket obviously still don’t run and keeping an extra.
Setting up a variable in ~/.zshrc (or ~/.bashrc if you’re on BASH): export INCUS_SOCKET="/run/incus/unix.socket"
…gets me closer to a better fix but there are now file access permission errors:
incus list
Error: You don't have the needed permissions to talk to the incus daemon (socket path: /run/incus/unix.socket)
ls -la /run/incus
"/run/incus": Permission denied (os error 13)
ls -la /run | grep incus
drwx------@ - root 17 jūl 11:33 incus
The bug is upstream in incus itself. I submitted a patch that was accepted yesterday. The daemon does a chmod 0700 on /run/incus on first start, which prevents the client from being able to see the incus socket at /run/incus/unix.socket. If you chmod 0711/run/incus, then the client can read the directory contents and will connect automatically (without having to set an environment variable)