Raising this as a discussion rather than an issue, as there may not be anything that can be done about it easily.
If you enter a container using incus shell, and the last thing you do before exiting is to attempt a non-existent command, then you get a confusing error message from incus after you have left the shell. It says: Error while executing alias expansion: incus exec <container> -- su -l
$ incus shell vtp-proxy
root@vtp-proxy:~# blah
-bash: blah: command not found
root@vtp-proxy:~# exit
logout
Error while executing alias expansion: incus exec vtp-proxy -- su -l
Error: Command not found
$
(Tested with incus 7.0.1 under Ubuntu)
I think this is because the failed exec in the shell sets returns code 127, which in turn is returned by the shell when it exits. This seems to confirm it:
$ incus shell vtp-proxy
root@vtp-proxy:~# exit 127
logout
Error while executing alias expansion: incus exec vtp-proxy -- su -l
Error: Command not found
$
I’m not sure what the “alias expansion” is that incus refers to. The only place I can find the error in the code is here:
// Default error handling
if os.Getenv("INCUS_ALIASES") == "1" {
fmt.Fprintf(os.Stderr, i18n.G("Error while executing alias expansion: %s\n"), shellquote.Join(os.Args...))
}
but I have not set INCUS_ALIASES at the client side:
$ echo "${INCUS_ALIASES:-unset}"
unset
and the daemon doesn’t appear to have it set either:
nsrc@server1:~$ ps auxwww | grep incusd | head -1
root 1932 0.5 0.1 7854636 155136 ? Ssl 10:50 1:04 incusd --group incus-admin --logfile /var/log/incus/incusd.log
nsrc@server1:~$ sudo cat /proc/1932/environ | tr '\0' '\n' | sort
HOME=/var/lib/incus/
INCUS_AGENT_PATH=/opt/incus/agent/
INCUS_DOCUMENTATION=/opt/incus/doc/
INCUS_EDK2_PATH=/opt/incus/share/qemu/
INCUS_LXC_HOOK=/opt/incus/share/lxc/hooks/
INCUS_LXC_TEMPLATE_CONFIG=/opt/incus/share/lxc/config/
INCUS_OPTS=
INCUS_UI=/opt/incus/ui/
INVOCATION_ID=abf9a14c124145f187fb6a43b5e4b08f
JOURNAL_STREAM=10:23656
LANG=en_GB.UTF-8
LD_LIBRARY_PATH=/opt/incus/lib/
LISTEN_FDNAMES=incus.socket
LISTEN_FDS=1
LISTEN_PID=1932
LISTEN_PIDFDID=32945
LXCFS_OPTS=
MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/system.slice/incus.service/memory.pressure
MEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA=
PATH=/opt/incus/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
PWD=/
SYSTEMD_EXEC_PID=1932
USER=root
I can see from cmd/incus-agent/exec.go than codes 126 and 127 are used to return exec failure to the parent (permission error or not found, respectively).
I guess solving this rigorously would involve some sort of channel from the child to the parent to signal whether and why exec() failed, rather than just relying on the exit status.
Anyway, I thought it was worth a mention because it’s user-visible behaviour, and just looks a bit weird.