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) – Wouter Verhelst Sep 29 '15 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 '15 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 '15 at 17:18

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.

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.