I'm writing about so many experiments and Unix Tutorial projects lately that I'm going to create a hardware lab section on this blog soon!
As you may know, I have a Raspberry Pi system named becky, and it has a 7" touchscreen attached to it. I recently started the Centralised RSyslog Project based around that Raspberry Pi system, and finally got the time to implement another super important improvement: configure tmux auto-start on the main Raspberry Pi screen.
Right now, Raspberry Pi screen shows a text login prompt. So before I can see any RSyslog logs or work with files, I have to attach keyboard, login with username and password and then use tail to review logs.
Since becky isn't my primary workstation, I don't have a dedicated keyboard for it. Which means after each reboot I have to find and reconnect keyboard to start logs monitoring.
I dediced to optimise this by using tmux. But if I SSH into Raspberry Pi and start tmux from command line, my tmux session won't show on the primary display (text console). So I want to find a way of auto-starting tmux with system boot AND on the primary text console.
Once this is done, I can always ssh remotely and reconnect to the tmux session – meaning anything I type or do via SSH will also be showing on the primary Raspberry Pi screen. Once I start the command I need, it should be possible to detach from tmux and to close my SSH session – but primary screen on Raspberry Pi will keep my commands running and showing.
Here's what I want to accomplish:
- automatically start tmux session with system boot
- ensure tmux starts on the primary screen of Raspberry Pi (so I can see it)
- eliminate the need to connect keyboard to Raspberry Pi in order to login
- create basic tmux startup script to allow for later improvements
Linux console: text login prompt
If you ever connected monitor to your Raspberry Pi or any server running Linux like CentOS/RedHat or Debian/Ubuntu, chances are you've seen the black screen with login prompt.
This login prompt is what's called a console login prompt – it's a level of protention created specifically around direct access to a sever or desktop. Much like Windows or MacOS system will show you a login screen when you power the system up or connect a monitor, Linux systems will do the same. But for servers you rarely have graphics login screen, so insted you're getting a text version of it.
You must enter a valid username and password to log into text console.
getty and tty1
Because Unix is always made for scale, your text console isn't everything there is to accessing your Linux remotely: in addition to attaching monitor you can also connect using serial or USB connection or via SSH.
All of such methons of access involve working with virtual consoles: special streams of interacting with your Unix system that are created every time and for every user accessing the server.
getty is one of the most common software implementations of managing virtual consoles – it's a command that allows you creating multiple virtual consoles for various kinds of access. So for login prompt on the screen you're attaching to Raspberry Pi, getty creates and manages the tty1 console.
Creating tmux start script
We'll need to write a simple script to start our tmux. Having this tmux.sh script will let you expand it later, to create multiple panes and starting different commands in them – all automatially.
I have a pretty basic script right now – it just starts tmux and gives me command line prompt. I called this script /home/greys/tmux.sh:
#!/bin/bash su greys -c "/usr/bin/tmux kill-session -t start 2> /dev/null" su greys -c "/usr/bin/tmux new-session -s start"
In this example, start is the name of my initial tmux session. And yes, this is a very simple way of achieving my result – I'll update this tutorial later showing a slightly more complex but also more correct waty of doing the same.
IMPORTANT: don't forget to make this script executable:
chmod a+rx /home/greys/tmux.sh
I suggest you try running this script now to see if it's working as expected (you should end up being inside a tmux session named start).
Auto-starting tmux in tty1
By default, each console like tty1 is running login prompt – with the idea that there's no way to access and to harm your Linux system without knowing username and password.
For my RSyslog server based on Raspberry Pi, I'm not particularly worried about unathorised access. More over, I'm interested in having easy enough way of changing what's shown in the text console of the Raspberry Pi screen. That's why I decided to replace default login with tmux auto-start.
IMPORTANT: please don't follow the same steps unless and until you have other means (SSH) of accessing your server remotely. There are ways to configure multiple virtual consoles, but in this tutorial I'm only showing how to override the default tty1, which means after you apply changes you may lose login promt to your system.
Update systemd to make getty start your script
Now that we have the tmux.sh script from previous step, let's configure systemd script to make getty start tmux.sh in tty1:
Here's how you can configure auto start of any software in your tty1 console (should be the default one in Ubuntu or Raspbian): you need to create the override.conf file in /firstname.lastname@example.org directory:
root@becky:/home/greys# cd /email@example.com root@becky:/firstname.lastname@example.org # vi override.conf [Service] ExecStart= ExecStart=-/home/greys/tmux.sh StandardInput=tty StandardOutput=tty
This will call the /home/greys/tmux.sh script instead of the default login.
Refresh systemd and restart getty service
The moment of truth: need to refresh systemd and restart getty to apply our changes.
IMPORTANT: login using SSH, do NOT run these commands from the primary screen/login console on your server.
# systemctl daemon-reload # systemctl restart email@example.com
If everything works fine, your screen on Raspberry Pi should show a tmux session like this one:
If something's not right, back out the changes before rebooting your Raspberry Pi:
# mv /firstname.lastname@example.org/override.conf /root # systemctl daemon-reload # systemctl restart email@example.com
Yes, you recognised it correctly: we simply move override.conf file out of the way and restart getty the same way we've done in previous step.
That's it for today!