I created an update routine for my device. The update process can be started using the serial console, SSH, telnet, a webserver or a REST API. Once the update started, I want to block all user input from all sources until the update is done and the device reboots. Killing SSH, telnet, the webserver and the REST server is easy, but I also want to block the input on the serial console.

So for that I have the following situation:

  • The user connects using the serial interface on /dev/ttyS0 / /dev/console.
  • If that shell session is closed, inittab respawns it
  • Once the upgrade starts I don't want the user to input anything on the console, so I'd like to block the input for that shell session.

I found that if I cat /dev/ttyS0 or cat /dev/console I can "steal" the input away from the shell, thus blocking input. And if I do (cat /dev/ttyS0 > /dev/null) & I can do that in the background and without seeing the input.

Is this method ok? Is there any reason why I shouldn't do that? Is there any better way?

  • This feels like an XY problem. Please clarify what the actual problem is you're trying to fix. (You almost certainly don't need to block all input to the console) Sep 29, 2015 at 13:24
  • Actually, this is exactly what I want to do. While the update runs, I really want to block all input from the user. The device is used by rather non-tech-savy users that, because of legacy reasons, have root access to the shell of the device. I really don't want any of these users to be able to abort the update and thus send the device to an undefined state. I know they can still pull the power chord, but apart from that I'd like to block all user input.
    – Dakkaron
    Sep 29, 2015 at 14:04
  • @Dakkaron The point is you don't want them to abort the update. Unless you're worried about them sending an explicit kill command, that means you don't want them hitting ^C to stop the update. That's easier to accomplish by making the update process not depend on terminal input, rather than making sure terminal input cannot do anything at all.
    – Random832
    Sep 29, 2015 at 17:18

1 Answer 1


I would suggest temporarily changing the init configuration so the shell isn't active for a moment.

Since you mention inittab, I'll assume you're using sysvinit. With that, you can do so by changing the inittab config file, and then running init q (which causes init to reread its configuration file and update internal state). Depending on the version of sysvinit and of the shell that's running on your serial console, you may also need to kill the shell itself explicitly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .