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_MAINTSCRIPT_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
  srw-rw---- 1 root root 0 May  1 18:22 /var/lib/lxd/unix.socket

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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1577001

Title:
  Installing lxd leaves /var/lib/lxd/unix.socket with wrong group
  ownership

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1577001/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to