Hi Sirs, Den 10. sep. 2016 17:34, skrev Herbert Poetzl: > On Sun, Sep 11, 2016 at 12:26:22AM +1200, Andrew Ruthven wrote: > >> 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. Although unrelated to the original question, how would you suggest to share and/or prioritize/select sound output from potentially a range of guests (or other sources) on the host? Giving /dev access to each guest would probably just work for the guest that first grabs the device ---- or maybe all sound just would be mixed together? - I have no idea! aRts, Phonon, PulseAudio, virtual sound device that pipes sound from guest to network stream....???? (I am just throwing out buzzwords here, as I have near to no clue on how the Linux sound system actually works and the state of it...! ;-) ) BR, Tor Rune Skoglund, trs@swi.no >> 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