How can I remotely (SSH) make my Linux Computer Beep (built-in speaker, as there are no external ones)? I have ubuntu 9.04 and can install extra packages if need be. This would be good for finding a certain box if you have more than one standing around and forgot which IP is which box.



sudo sh -c "echo -e '\a' > /dev/console"

You may have to load the kernel module for the built-in speaker first (e.g. if the module was blacklisted from auto-loading):

sudo modprobe pcspkr
| improve this answer | |
  • This worked while the beep command did not. I just set this to run on a coworkers machine. for i in seq 1 10000; do echo -e '\a' > /dev/console; sleep 1; done – Nick Stinemates Sep 28 '09 at 21:08
  • 1
    Didn't make a sound. – Nick Stinemates Sep 28 '09 at 23:07
  • This works well on CentOS / RHEL, I couldn't find any beep packages. – plasmid87 Mar 29 '12 at 15:38
  • @NickStinemates Make sure you have a PC speaker on your motherboard – dykeag Mar 28 '13 at 23:15
  • This is the easiest solution! Also, sorry for only accepting 9 years late. – wsd Oct 22 '18 at 23:23


modprobe pcspkr

then solutions from topic, like

ssh user@host
| improve this answer | |

From the beep man page on my Ubuntu machine:


Some users will encounter 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.

This could well be the reason why beep refuses to work remotely. You can check if this is the root cause by invoking ssh with the -t option, which forces pseudo-tty allocation.

A less desirable solution would be to create a wrapper script that executes beep, and grant this script root permissions. If executing this script over ssh duly produces a beep, you'll know that the issue is the lack of a controlling terminal.

| improve this answer | |

Just type

ssh user@remote-machine

Tested on Ubuntu Desktop 8.x, this will beep on the remote server, even if no local session on that server is active (thus: even if the GNOME login screen is shown on the monitor attached to the server).

Have a look at

man beep

for more details. On Debian/Ubuntu, the beep package has to be installed and the speakers must not be muted.

| improve this answer | |
  • I wonder why you wrote "the speakers must not be muted". My Ubuntu Desktop box has no sound drivers installed, and indeed both beep and the echo options all use my built-in speaker. Though man beep clearly states "beep the pc speaker any number of ways", I have not verified what happens if one has sound drivers installed. – Arjan Sep 27 '09 at 22:36
  • At least on my pc I can mute the speakers with gnome-volume-control. And since I can't stand the beeping, I usually do. – Kim Sep 28 '09 at 3:15
  • So, then beep does not use the built-in speaker on your system? Or does the volume control (which is disabled on my Ubuntu box) also control the built-in speaker? Might be fun to see if the echo solutions behave different than. – Arjan Sep 28 '09 at 9:19
  • gnome-volume-control can be used to control the built-in speaker separately. What do you mean by disabled? What happens when you run gnome-volume-control from a command line? – Kim Sep 28 '09 at 16:14
  • Sorry, just wiped out that 10.8 install. Disabled as in: no sound drivers installed, and therefore a stop-sign on top of the sound-icon in the GNOME menu. – Arjan Sep 28 '09 at 21:23

You can use:

ssh user@remote-machine
sudo sh -c "echo -e '\a' > /dev/tty1"

Note that the following would not work. It fails before even prompting for the sudo password because the (bash) shell is doing the redirection, and that shell still runs as the normal user, not as root:

ssh user@remote-machine
sudo echo -e '\a' > /dev/tty1
-bash: /dev/tty1: Permission denied
ls -la /dev/tty1
crw------- 1 root root 4, 1 2009-09-28 16:33 /dev/tty1
| improve this answer | |

This command will do the trick:

modprobe pcspkr; echo -e "\a" > /dev/console;
| improve this answer | |

Run a remote command to the remote machine:

rsh hostname /usr/bin/echo '\a'
ssh user@remotehost /usr/bin/echo '\a'

| improve this answer | |
  • Wouldn't one need the redirection to some remote terminal like Thomas suggested, to get the remote server to beep, rather than the local SSH client? – Arjan Sep 27 '09 at 20:19
  • One can also do : echo "\a" > 'tty'. – harrymc Sep 28 '09 at 6:18
  • echo -e "\a" > /dev/tty surely would beep on the SSH client, not on the built-in speaker on the server :-) tty0, tty1 and console seem to work, as shown in other answers. – Arjan Sep 28 '09 at 14:05

Or, you could simply run the following once:

chmod o+x `which beep`

This will allow all users to use the beep executable, which probably is safe enough in most cases.

| improve this answer | |

This all works perfect after logging in and opening a tty device. When for instance you want a beep from rc.local to know when your linux machine is ready booting, like a intel nuc, run this script /root/bin/boot-complete.sh from /etc/rc.d/rc.local :

# this is /root/bin/boot-complete.sh

/sbin/modprobe pcspkr
/bin/sleep 1
/usr/bin/aumix -p 75
echo -e '\a' > /dev/tty1 2>&1
/bin/sleep 1
echo -e '\a' > /dev/tty1 2>&1

exit 0
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.