root@server:~# lxc
-bash: lxc: command not found
Anyway, my containers are (still…?) running and can be seen in:
systemctl status
PC
lxd under snap under debian stretch
Hi!
I dare to guess that the root shell did not parse the full environment (i.e. is not a login shell)
therefore, the directory /snap/bin is not in your $PATH for this session.
To verify, run /snap/bin/lxc.
To fix, use a login shell so that /snap/bin/ gets into your $PATH.
Thank you. /snap/bin is empty:
root@server:~# ls -lh /snap
total 4.0K
drwxr-xr-x 1 root root 0 Feb 6 19:57 bin
drwxr-xr-x 1 root root 22 Jan 28 10:57 core
drwxr-xr-x 1 root root 30 Feb 6 19:57 lxd
-r--r--r-- 1 root root 548 Jan 27 22:53 README
root@server:~# ls -lh /snap/lxd/
total 0
drwxr-xr-x 17 root root 247 Jan 27 19:27 13162
drwxr-xr-x 17 root root 247 Feb 3 09:58 13253
drwxr-xr-x 17 root root 247 Feb 6 16:31 13300
root@server:~# ls -lha /snap/bin
total 0
drwxr-xr-x 1 root root 0 Feb 6 19:57 .
drwxr-xr-x 1 root root 32 Jan 28 10:58 ..
root@server:~#
is snap even installed (dpkg --get-selections | grep snapd), if yes, is it running (ps fauxww | grep snapd) and if yes what gives snap refresh ?
snap has been installed.
lxd has been installed
And lxd is running correctly…
root@server:~# dpkg --get-selections | grep snapd
snapd install
root@server:~# ps fauxww | grep snapd
root 633 2.2 0.3 3137572 26480 ? Ssl Feb06 42:00 /usr/lib/snapd/snapd
root 20650 0.0 0.0 6076 828 pts/2 S+ 15:26 0:00 | \_ grep snapd
root@server:~# ps fauxww | grep lxd
root 20658 0.0 0.0 6076 888 pts/2 S+ 15:26 0:00 | \_ grep lxd
root 1004 0.0 0.0 234844 0 ? Sl Feb06 0:00 lxcfs /var/snap/lxd/common/var/lib/lxcfs -p /var/snap/lxd/common/lxcfs.pid
root 1111 0.0 0.0 289844 704 ? Ss Feb06 0:00 [lxc monitor] /var/snap/lxd/common/lxd/containers bind
root 1188 0.0 0.0 288436 696 ? Ss Feb06 0:00 [lxc monitor] /var/snap/lxd/common/lxd/containers debian
root 1305 0.0 0.0 298040 624 ? Ss Feb06 0:00 [lxc monitor] /var/snap/lxd/common/lxd/containers mail
root 1428 0.0 0.0 298040 740 ? Ss Feb06 0:00 [lxc monitor] /var/snap/lxd/common/lxd/containers pgsql
root 1577 0.0 0.0 290100 124 ? Ss Feb06 0:00 [lxc monitor] /var/snap/lxd/common/lxd/containers sip
root 1783 0.0 0.0 304828 116 ? Ss Feb06 0:00 [lxc monitor] /var/snap/lxd/common/lxd/containers www
root@server:~# which lxc
root@server:~# which snap
/usr/bin/snap
Well lxd is running correctly… But for how a long time ?
…
not so much…
ps fauxww | grep lxd | grep daemon
root 26070 0.0 0.0 4500 1736 ? Ss 14:44 0:00 /bin/sh /snap/lxd/13300/commands/daemon.start
and what gives snap refresh ???
Nthing, you can see it above with the:
ps fauxww | grep lxd
I do not dare try:
snap refresh
fearing to loose all my containers…
that’s my point, you don’t have the lxd daemon running.
re: losing your containers, if you can connect to your containers using ssh, try to save what you can from there with traditional ways
Sure, if you have got where you are after a rm -rf session, there is something to lose by running about anything that is not a backup.
I do not know what has created the problem, but I think the surest way is to reinstall a full clean system from the saved containers… Fine, a good task for the WE, I love !
But it is true that in these lxd days, it is a 2 hours job…
If you have good backups I don’t see what you could lose by running snap refresh and if it works it would beat reinstalling everything.
I have not read your post before this morning. So as I did not know how snap works in case of disaster, I did remove snapd (with a few reboots and remove a few caches…), reinstall snap, lxd, and reimport backup containers, the whole in a small hour without need of a full reinstall…
I have no explanation of what did occur, except I did not "rm /snap/bin/*… but, it is a good exemple of lxd flexibility