Subject: Re: [vserver] Sound devices under vservers?
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Sat, 10 Sep 2016 17:34:21 +0200

On Sun, Sep 11, 2016 at 12:26:22AM +1200, Andrew Ruthven wrote:
> Hye,

Hey Andrew!

> On Wed, 2016-09-07 at 18:57 +0200, Herbert Poetzl wrote:
>> On Wed, Sep 07, 2016 at 11:33:48PM +1200, Andrew Ruthven wrote:
>>>  
>>> I run slimserver and squeezelite within a vserver, and until
>>> recently they've worked nicely. But now squzeelite (which
>>> actually plays the music out a soundcard) has stopped working.
>> The files in /dev/snd within the container still match what is
>>> on the hypervisor.

>> There is no hypervisor in Linux-VServer.
>> There is a kernel and a host system and a number of guests.

> Yeah, I was just stealing the language from elsewhere. ;)

Don't do that ;)

>>> Running strace when I start squeezelite gives me:

>>> open("/dev/snd/controlC0", O_RDONLY|O_CLOEXEC) = 4
>>> fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
>>> ioctl(4, SNDRV_CTL_IOCTL_CARD_INFO or UI_DEV_CREATE,
>>> 0x7ffcc50789d0) =
>>> -1 ENOTTY (Inappropriate ioctl for device)

>> Try to run squeezelite with strace in a chroot into the guest
>> and see if the result differs. 

>> If you get the same result, then the isolation (Linux-VServer 
>> is not involved). 

>> If it works inside the chroot but fails inside the guest, then
>> you might have insufficient capabilities.

> Okay, fails within a chroot as well. Relevant lines:

>> From the host (setting LD_LIBRARY_PATH to pick up the libraries within
> the guest):

> open("/dev/snd/controlC0", O_RDONLY|O_CLOEXEC) = 4
> fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
> ioctl(4, SNDRV_CTL_IOCTL_CARD_INFO or UI_DEV_CREATE, 0x7ffc646fd6d0) =
> 0
> close(4)                                = 0

> Within a chroot:

> open("/dev/snd/controlC0", O_RDONLY|O_CLOEXEC) = 4
> fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
> ioctl(4, SNDRV_CTL_IOCTL_CARD_INFO or UI_DEV_CREATE, 0x7ffd93373400) =
> -1 ENOTTY (Inappropriate ioctl for device)
> close(4)                                = 0

> Within the guest:

> open("/dev/snd/controlC0", O_RDONLY|O_CLOEXEC) = 4
> fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
> ioctl(4, SNDRV_CTL_IOCTL_CARD_INFO or UI_DEV_CREATE, 0x7ffd6119bd40) =
> -1 ENOTTY (Inappropriate ioctl for device)
> close(4)

> Aw crap. Turns out the minor numbers were different for
> /dev/snd/controlC0 between the host and the guest. I had
> initially looked at those and thought they matched, guess I
> read them wrong.

> I guess I should add a step to my start script for the guest to
> always copy over the contents of /dev/snd.  ;)  Actually, now
> it's a bind mount.

A bind mount should be fine, either of the snd dir if you
want to share all audio devices with the guest or of the
individual entries. Copy works also if the devices do not
change during the lifetime of the guest.

> Sorry to distract folks, but I thought I'd respond with the
> details and the cause in case other folks hit it.

No problem! Thanks for the update though!

All the best,
Herbert

> Cheers,
> Andrew

> -- 
> Andrew Ruthven, Wellington, New Zealand
> MIITP, ITCP

> At work: andrew.ruthven@catalyst.net.nz
> At home: andrew@etc.gen.nz
> Cloud  : NZs only real cloud - https://catalyst.net.nz/cloud
> GPG fpr: C603 FC4E 600F 1CEC D1C8  D97C 4B53 D931 E4D3 E863
> LCA2017: The Future of Open Source, Hobart, AU - http://linux.conf.au