This exhibits a bug in lxd's maintainer scripts: Purging lxd still leaves lxd.socket running. Re-adding an lxd task about this, it needs the counterpart of starting lxd.socket in the postinst.
> Adding logging to the package's postinst shows that, if /var/lib/lxd/unix.socket did not already exist, it is created by the line
> deb-systemd-helper enable lxd.service
Most of "deb-systemd-helper enable" shouldn't affect the permissions of unix.socket at all, as this is just creating symlinks in /etc/systemd/system/ (without even calling systemctl for that). So I figure the "systemctl daemon-reload" at the very end triggers this. And indeed:
This is inconsistent -- either unix.socket should not be created at all (as the unit is still running) or with correct permissions.
@Dan: Is this reproducible for you on a 16.04 install that has lxd purged, no /var/lib/lxd/unix.socket, and lxd.socket *not* running? (Note that 16.04 comes with lxd preinstalled on server and cloud images) I. e. do you only see this on reinstall or on a clean install of lxd? If so, we have another bug, but if "systemctl status lxd.socket" is running before the reinstall it's the issue I described above.
I can reproduce this bug in a small (autopkgtest) Xenial VM with
dpkg -P lxd; rm /var/lib/ lxd/unix. socket; apt-get install -y lxd; ls -l /var/lib/ lxd/unix. socket
But I cannot reproduce this as long as the lxd package is already installed, all these work fine:
systemctl stop lxd.{service, socket} lxd-containers; rm /var/lib/ lxd/unix. socket; systemctl reset-failed lxd.{service, socket} lxd-containers; DEBIAN_ FRONTEND= noninteractive dpkg-reconfigure lxd; ls -l /var/lib/ lxd/unix. socket
systemctl stop lxd.{service, socket} lxd-containers; rm /var/lib/ lxd/unix. socket; systemctl reset-failed lxd.{service, socket} lxd-containers; DEBIAN_ FRONTEND= noninteractive apt-get install --reinstall lxd; ls -l /var/lib/ lxd/unix. socket
systemctl stop lxd.{service, socket} lxd-containers; rm /var/lib/ lxd/unix. socket; systemctl reset-failed lxd.{service, socket} lxd-containers; export DPKG_MAINTSCRIP T_PACKAGE= lxd; deb-systemd-helper enable lxd.service; deb-systemd-helper enable lxd.socket; deb-systemd-helper enable lxd-containers. service; deb-systemd-invoke start lxd-containers. service; deb-systemd-invoke start lxd.socket; ls -l /var/lib/ lxd/unix. socket
(The reset-failed is to avoid the "unit restarted too often" rate limit when running these too often)
More interestingly, I also cannot reproduce the bug with the first command if I stop the socket unit before or after purging:
systemctl stop lxd.socket; dpkg -P lxd; rm /var/lib/ lxd/unix. socket; apt-get install -y lxd; ls -l /var/lib/ lxd/unix. socket
dpkg -P lxd; systemctl stop lxd.socket; rm /var/lib/ lxd/unix. socket; apt-get install -y lxd; ls -l /var/lib/ lxd/unix. socket
This exhibits a bug in lxd's maintainer scripts: Purging lxd still leaves lxd.socket running. Re-adding an lxd task about this, it needs the counterpart of starting lxd.socket in the postinst.
> Adding logging to the package's postinst shows that, if /var/lib/ lxd/unix. socket did not already exist, it is created by the line
> deb-systemd-helper enable lxd.service
Most of "deb-systemd-helper enable" shouldn't affect the permissions of unix.socket at all, as this is just creating symlinks in /etc/systemd/ system/ (without even calling systemctl for that). So I figure the "systemctl daemon-reload" at the very end triggers this. And indeed:
mv /lib/systemd/ system/ lxd.socket{ ,.disabled} ; systemctl daemon-reload; sleep 0.5; mv /lib/systemd/ system/ lxd.socket{ .disabled, }; systemctl daemon-reload; sleep 0.5; ls -l /var/lib/ lxd/unix. socket lxd/unix. socket
srw-rw---- 1 root root 0 May 1 18:22 /var/lib/
This is inconsistent -- either unix.socket should not be created at all (as the unit is still running) or with correct permissions.
@Dan: Is this reproducible for you on a 16.04 install that has lxd purged, no /var/lib/ lxd/unix. socket, and lxd.socket *not* running? (Note that 16.04 comes with lxd preinstalled on server and cloud images) I. e. do you only see this on reinstall or on a clean install of lxd? If so, we have another bug, but if "systemctl status lxd.socket" is running before the reinstall it's the issue I described above.