On Mon, 31 Jul 2017, Juan R. de Silva wrote:
Hi folks,
I installed (fresh install instead of an upgrade) Debian Stretch on my laptop.
The installation is full success without any problem except a little one -
'beep' does not produce a sound neither from CLI nor from a bash scripts. I had
Jessie installed on the same laptop before and it worked just fine.
I checked everything I possibly could: pcspkr module loaded, alsa does not have
any muted channels, tried to use it as a user and as a root. No clue why it does
not work any longer in Strech.
Any suggestions?
Possibly the following excerpt from https://github.com/johnath/beep/
applies. (TLDR: Skip to the end, read the last three quoted lines.)
| A note about ioctl
| ------------------
| As noted in the man page, some users are running into a situation
| where beep dies with a complaint from ioctl(). The reason for this,
| as Peter Tirsek was nice enough to point out to me, stems from how
| the kernel handles beep's attempt to poke at (for non-programmers:
| ioctl is a sort of catch-all function that lets you poke at things
| that have no other predefined poking-at mechanism) the tty, which is
| how it beeps. The short story is, the kernel checks that either:
| - you are the superuser
| - you own the current tty
| What this means is that root can always make beep work (to the best
| of my knowledge!), and that any local user can make beep work, BUT a
| non-root remote user cannot use beep in it's natural state. What's
| worse, an xterm, or other x-session counts, as far as the kernel is
| concerned, as 'remote', so beep won't work from a non-priviledged
| xterm either. I had originally chalked this up to a bug, but
| there's actually nothing I can do about it, and it really is a Good
| Thing that the kernel does things this way. There is also a
| solution.
| By default beep is not installed with the suid bit set, because that
| would just be zany. On the other hand, if you do make it suid root,
| all your problems with beep bailing on ioctl calls will magically
| vanish, which is pleasant, and the only reason not to is that any
| suid program is a potential security hole. Conveniently, beep is
| very short, so auditing it is pretty straightforward.
| Decide for yourself, of course, but it looks safe to me - there's
| only one buffer and fgets doesn't let it overflow, there's only one
| file opening, and while there is a potential race condition there,
| it's with /dev/console. If someone can exploit this race by
| replacing /dev/console, you've got bigger problems. :)
| So the quick solution is beep is not beeping when you want it to is:
| $ su
| Password:
| # chmod 4755 /usr/bin/beep
| (or wherever you put it)
| The one snag is that [making beep suid root] will give any little
| nitwit the ability to run beep successfully - make sure this is what
| you want. If it isn't, a slightly more complex fix would be
| something like:
| # chgrp beep /usr/bin/beep
| # chmod 4750 /usr/bin/beep
| and then add only beep-worthy users to the 'beep' group.
