7

I know that I can set a TMOUT variable to automatically end a bash session after a specified period of inactivity. However, what I want is to apply that only to my 6 built-in virtual consoles, which are accessed by ctrl+alt+{F1...F6}.

I almost always use a Terminal app when I want to open a terminal. When I leave my computer, I lock the screen, which prevents anyone from accessing those terminals. So I would like to not have a timeout on those.

However, on rare occasions I will use one of my virtual consoles to work on my computer. Usually it is due to my main Gnome session being frozen or otherwise unusable. I kill the offending app, then switch back to my main session.

On top of that, a few times I have forgotten to exit out of my virtual console when I have restored my Gnome session. Thus, my computer is completely unprotected if I walk away, since locking the screen on Gnome only locks the GUI; a user could switch to a virtual console and kill my gnome lockscreen or otherwise mess with my computer.

Can I set a timeout value for the built-in virtual consoles only, while allowing a Terminal app session to remain inactive indefinitely?

|improve this question
8

You could check if you are running in a graphical terminal and only set TMOUT if you are not. An easy way to do this is the tty command:

   tty - print the file name of the terminal connected to standard input

When run from a GUI terminal emulator:

$ tty
/dev/pts/5

When run from a virtual console:

$ tty
/dev/tty2

So, adding these lines to your ~/.profile should kill your bash session after ten minutes:

tty | grep tty >/dev/null && TMOUT=600
|improve this answer
  • You don't want to export TMOUT. That would affect the read builtin of all bash or ksh93 script started from your login session. – Stéphane Chazelas May 24 '16 at 16:25
  • @StéphaneChazelas yes, isn't that what the OP wants? If they want their session to exit after 10 minutes, they also, presumably, want their scripts to exit as well. They will be killed when the session ends in any case, after all. – terdon♦ May 25 '16 at 9:23
  • TMOUT on read doesn't cause scripts to end, it causes read to fail after a timeout, which could make scripts fail in every possible way. It's unlikely to cause problems as it would be rare for read to hang for 10 minutes, but it's still wrong to export TMOUT (also note that once exported, if a script does TMOUT=1 it will affect all scripts called from within that script instead of just the script itself). – Stéphane Chazelas May 25 '16 at 9:50
  • @StéphaneChazelas OK. Simply setting it would be OK and should still do what the OP needs though, right? – terdon♦ May 25 '16 at 9:55
  • Yes, though then I'd probably do it in ~/.bashrc so it affects all interactive shells, not only the login one (and assuming ~/.profile or ~/.bash_profile sources ~/.bashrc as one need to do to work around that bash bug). tty | grep -q 'tty[0-9]' to avoid considering ttyUSB3 or ttyS1. – Stéphane Chazelas May 25 '16 at 10:18
1

This is a good case for the pam_env.so PAM module. Virtual console logins use the login program, so you can open /etc/pam.d/login and add a line such as the following:

session  required  pam_env.so  readenv=1 envfile=/etc/vc-environment user_readenv=0

With the accompanying new file, /etc/vc-environment:

TMOUT=600

Two advantages to using PAM for this:

  • It applies to any user who logs into the virtual console (although it does not stop them from changing TMOUT later).
  • The timeout can be applied to other specific services as well, such as sudo.

Read here for details on this module.

|improve this answer
  • You don't want to export TMOUT. That would affect the read builtin of all bash or ksh93 script started from your login session. – Stéphane Chazelas May 24 '16 at 16:27
  • PAM's session management occurs before the service is given at all, so I don't think that a shell's variable exporting comes into play here. My testing showed that setting TMOUT this way affected the read builtin regardless of the presence of an export-type keyword in the environment file. – billyw May 24 '16 at 16:53
  • 1
    Sorry, that was a straight copy-paste from my comment to @terdon's answer, I should have edited it. The idea is the same though. TMOUT shouldn't be but in the environment as like other shells special variables like IFS, CDPATH or FIGNORE, they affect not only your interactive shell but also the behaviour of scripts. – Stéphane Chazelas May 24 '16 at 19:46
0

I never liked the TMOUT solution. First, because it only works if you leave your session at the prompt; if you leave it inside Vim or even at a sudo password prompt, it won't time out. And second, I don't want the session to be closed, I want it to be locked, just like the graphical environments do.

GNU Screen is able to lock after an idle period, so I did the following. At the very beginning of my ~/.bashrc I added this:

if [ "$TERM" = "linux" ] && tty | egrep -q '^/dev/tty[[:digit:]]+$'
then
    exec screen -c ~/.ttyscreenrc
fi

The exec is important, because it ensures screen replaces Bash, and when it ends the TTY session will be closed.

And in ~/.ttyscreenrc I put this:

startup_message off
idle 180 lockscreen

To skip Screen's welcome screen and lock after 3 minutes of inactivity.

|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.