Erratic proxy device error `bind: no such file or directory` for Pulseaudio

1

I am getting a seemingly erratic error when launching a container. Sometimes the launch works and most of the times it does not.

$ lxc launch ubuntu:18.04 --profile default --profile x11 mycontainer
Creating mycontainer
Starting mycontainer
Error: Error occurred when starting proxy device: Error: Failed to listen on /home/ubuntu/pulse-native: listen unix /home/ubuntu/pulse-native: bind: no such file or directory
Try `lxc info --show-log local:mycontainer` for more info

The LXC profile is:

config:
  environment.DISPLAY: :0
  environment.PULSE_SERVER: unix:/home/ubuntu/pulse-native
  nvidia.driver.capabilities: all
  nvidia.runtime: "true"
  user.user-data: |
    #cloud-config
    runcmd:
      - 'sed -i "s/; enable-shm = yes/enable-shm = no/g" /etc/pulse/client.conf'
    packages:
      - x11-apps
      - mesa-utils
      - pulseaudio
    write_files:
      - owner: root:root
        permissions: '0644'
        append: true
        content: |
          PULSE_SERVER=unix:/home/ubuntu/pulse-native
        path: /etc/environment
description: GUI LXD profile
devices:
  PASocket1:
    bind: container
    connect: unix:/run/user/1000/pulse/native
    listen: unix:/home/ubuntu/pulse-native
    security.gid: "1000"
    security.uid: "1000"
    uid: "1000"
    gid: "1000"
    mode: "0777"
    type: proxy
  X0:
    bind: container
    connect: unix:@/tmp/.X11-unix/X1
    listen: unix:@/tmp/.X11-unix/X0
    security.gid: "1000"
    security.uid: "1000"
    type: proxy
  mygpu:
    type: gpu
name: x11
used_by: []

The log output:

$ lxc info --show-log local:mycontainer             
Name: mycontainer
Location: none
Remote: unix://
Architecture: x86_64
Created: 2020/04/19 05:07 UTC
Status: Running
Type: container
Profiles: default, x11
Pid: 25646
Ips:
  eth0:	inet	10.67.174.70	veth4755ada3
  eth0:	inet6	fd42:e196:7303:cb4f:216:3eff:fe6d:48b	veth4755ada3
  eth0:	inet6	fe80::216:3eff:fe6d:48b	veth4755ada3
  lo:	inet	127.0.0.1
  lo:	inet6	::1
Resources:
  Processes: 53
  Disk usage:
    root: 372.18MB
  CPU usage:
    CPU usage (in seconds): 138
  Memory usage:
    Memory (current): 421.92MB
  Network usage:
    eth0:
      Bytes received: 147.40MB
      Bytes sent: 1.65MB
      Packets received: 35745
      Packets sent: 18693
    lo:
      Bytes received: 44.32kB
      Bytes sent: 44.32kB
      Packets received: 378
      Packets sent: 378

Log:

lxc mycontainer 20200419050709.478 ERROR    cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1143 - File exists - Failed to create directory "/sys/fs/cgroup/cpuset//lxc.monitor.mycontainer"
lxc mycontainer 20200419050709.479 ERROR    cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1143 - File exists - Failed to create directory "/sys/fs/cgroup/cpuset//lxc.payload.mycontainer"
lxc mycontainer 20200419050709.480 ERROR    utils - utils.c:lxc_can_use_pidfd:1855 - Invalid argument - Kernel does not support waiting on processes through pidfds
lxc mycontainer 20200419050709.483 WARN     cgfsng - cgroups/cgfsng.c:fchowmodat:1455 - No such file or directory - Failed to fchownat(17, memory.oom.group, 1000000000, 0, AT_EMPTY_PATH | AT_SYMLINK_NOFOLLOW )

By the way, I believe, this log does not show anything relevant for this problem. When I launch a container with the default profile, I get the same errors.

Could this be due to a problem on the host? How can I troubleshoot this?

2

That would be because /home/ubuntu does not exist in this image until it’s completed its first boot. That path is created by cloud-init during first boot.

3

It is a race condition then, and the instructions should be ammended.

The PulseAudio socket is placed in the home directory of the container so that snap packages that at least use the [home] plug can work. Audio would not work if the socket is placed in /tmp, since most snaps have private /tmp directories.

The canonical location is just like on the host, but I remember failures when trying to create proxy devices over /run/.... Will need to recheck.

4

Using images:ubuntu/bionic should work as I believe those ship with the account.

5

Thank you for your feedback. One other ‘impression’ I had was that this only happened when no container existed on my host. When there was a ‘working’ container using the same base image, it then worked for the additional containers with the same image without such error. However this was only a subjective impression…

Since those are ‘only’ desktop application containers that live for longer periods and the two containers I use for this purpose are working now, I will not spend more time on this for now.

Thank you for your help!