Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an instance of Ubuntu 12.04 LTS (GNU/Linux 3.2.0-25-virtual i686) running as a KVM-VM on a host-machine that runs one more VM beside it.

I deploy a Ruby on Rails application using the Capistrano deployment-gem.

However, if I deploy twice in a row in a short time, the CPU usage jumps to 100% because of the /sbin/getty process.

How can this be?

I believe getty is a rather simple program that passes a login-name from a terminal to a login-process.

Also: In my Capfile (Capistrano configuration file) I am running certain commands after the Rails application is deployed including a call to sudo /sbin/restart <APPNAME> which is an upstart task.

Could this be related somehow?

I can always kill the getty process and the problem is gone until the next deployment, but I would rather understand and fix the problem.

Any help is appreciated. Attached is a screenshot of my problem.

/sbin/getty causes 100% CPU load

share|improve this question
You can trace what the getty is doing with 'strace -f -p 18081' where 18081 is the pid of the misbehaving getty. If strace doesn't show anything, its likely a bug in getty. – SpamapS Aug 18 '12 at 14:09
Were you able to solve this issue permanently? – Christoph Geschwind Feb 6 '14 at 17:31

Finally I also encountered this issue on a Ubuntu 12.10 Server VPS.

But as I don't need any tty (because I'm connecting by ssh) I fixed it the hard way:

sudo rm /etc/init/tty*
sudo reboot

And it works pretty well! no more getty process stuck.

share|improve this answer

I'm experiencing exactly the same issue on my Raspberry Pi running debian wheezy/sid

When I restart one of my daemons with sudo restart daemon-name, getty start eating all the CPU.

htop output

I've run strace -f -p 9052 to see what's happening, and what I got is an infinite loop of:

read(0, "", 1)                          = 0
read(0, "", 1)                          = 0
read(0, "", 1)                          = 0
read(0, "", 1)                          = 0
read(0, "", 1)                          = 0

I probaly have an issue in my upstart script because when I stop it with sudo stop daemon-name, the underlying process keeps running, I have to kill it by hand (with a simple SIGTERM). If I start it again with sudo start daemon-name after killing the process, there is no issue with getty at all.

So I guess this is linked to the fact that sudo restart doesn't stop my daemon and start a new one, but my daemon can run twice fine, and does not cause this issue if I just run it twice by hand.

So this should come from upstart or getty. I'll investigate more with my upstart script.

I've now fixed my upstart script, it didn't fix the getty issue.

share|improve this answer

Are you logging to syslog?

Is your syslog going to tty1?

If so, there's a good chance you have more than 38400bps worth of syslog and getty is blocking while it waits to dump data into its tty.

I'd check your rsyslog configuration - by default, Ubuntu logs some syslog output to /dev/xconsole via /etc/rsyslogd.d/50-default.conf.

share|improve this answer
If this is the case, how to prevent it? – knownasilya Sep 22 '15 at 14:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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