BSD

Install and Use tmux in FreeBSD

I’ve recently (re)discovered how beneficial tmux is when managing my small FreeBSD-based home server (running FreeBSD 14.0-RELEASE-p5 at time of this post). According to the FreeBSD man pages, tmux is a terminal multiplexer that it enables a number of terminals to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue in the background, then later reattached.

My FreeBSD servers run headless so I typically administer them from the command line via SSH connections. Thanks to tmux, I can have one or more terminal sessions operating simultaneously over a single SSH connection. But what I appreciate even more is that should my connection to a server fail for any reason, my terminal session will be maintained by tmux, allowing me to pick right back up where I left off when the SSH connection can be reestablished.

I’m using FreeBSD binary packages instead of ports these days so to install tmux (version 3.3a_1 at the time of this post) I first update the package repository on the system then install tmux as the user root:

Once installed I logged into my system through SSH and start tmux:

Optionally I can name my session by passing the parameter -s [your-session-name] to tmux when I start it. For example:

When tmux is started it creates new terminal session within a single window. A green status line appears at the bottom of the screen. This is used to show information about the session as well as for entering commands. Now that I’m connected to tmux, I can run any commands or programs I normally would.

Let’s test to make sure tmux is working as as it should by running the the table of processes or “top” command to display information on your system’s CPU(s) and running processes.

Now that top is running, I can detach from tmux using the command Ctrl+b followed by d, leaving top running in active in memory. Now I’ll end my SSH session and reconnect. In order to get back to my running instance of top I need only reattach to tmux.

And I now see top running just as I had left it. You can see the value of tmux in this example. If I were to lose SSH connection to a server for whatever reason, any work I was doing would still be running under tmux when I reestablish my connection.

I can also run two or more terminal sessions simultaneously in tmux. To do this I create a new window using the command Ctrl+b followed by c. Each of these windows is assigned an index number (e.g., 0,1,.. ) and those are shown in the green status line. I can now navigate between these windows using Ctrl+b followed by the number assigned to them , or by using Ctrl+b followed by n (next) or p (previous).

Another handy command is Ctrl+b followed by w, which opens a panel allowing me to chose a window interactively.

Here is a list of the keybindings I find useful. You can view a list of all of the keybindings that tmux offers by using the command Ctrl+b followed by ? or by consulting the tmux man pages.

Ctrl+b ?   View all keybindings. Press q to exit.
Ctrl+b d   Detach from the current session.
Ctrl+b c   Create a new window.
Ctrl+b x   Close window.
Ctrl+b n or p   Move to the next or previous window.
Ctrl+b 0 (1,2…)   Move to a specific window by number.
Ctrl+b w   Open a panel to navigate across windows in multiple sessions.

Conclusion

I’ve really enjoyed getting back into using tmux. It’s made managing my servers more productive as well giving me piece of mind knowing that I can safely return to what I was doing should I lose my SSH connection.

References
https://man.freebsd.org/cgi/man.cgi?query=tmux
https://github.com/tmux/tmux/wiki

BSD

The FreeBSD top command

Hey, howdy. Yeah, I know, it’s been awhile.

Here’s a very short post on the FreeBSD top command, mostly because I was using it the other day and it was um…, top of mind (sorry).

The table of processes or “top” command can be used to display information on your FreeBSD system’s CPU(s) and running processes. By default top lists the processes based on their CPU usage, and will update the list every second. Here are a few of the top options I find handy:

-h   Summarizes the options available for top

-a   Displays the command name and its full path, rather than just its executable name.

-H   Display each thread for a multi-threaded process individually. By default a single summary line is displayed for each process.

-I   Toggles the display of idle processes. By default, top displays both active and idle processes.

-m   Display statistics based on either I/O or CPU usage. The default is CPU.

-S   Display system processes. Normally, system processes such as pagedaemon and clock are not shown.

References

https://man.freebsd.org/cgi/man.cgi?top(1)
https://klarasystems.com/articles/explaining-top1-on-freebsd/

Games

How to Fix the Infinite Loading Screen Problem in Fallout: New Vegas

With the Corona-19 virus curbing my outdoor activities I decided to have another go at playing Fallout: New Vegas on PC. For this play through I bought the game anew from GOG.com. GOG has done an excellent job of fixing most of the bugs, crashes and other problems that continue to plague the version of the game available from Steam. One intermittent problem that remains, however, is an an infinite loading screen. When this happens the actual game will not launch and game play cannot continue. Very annoying.

A simple work-around for this problem is to start a new game. Note that you’ll want to retain any saves you may have to this point. You’ll wake up Doc Mitchell’s house where you’ll once again be guided though creating your character. It doesn’t matter whether you create the same character or not. When Doc Mitchell is done with you and you’ve regained control of your character create a hard save at this point. Now, next time you encounter a loading screen that goes on forever, restart the game and load that save. Once in the game you can simply reload one of your old saves.

Good hunting!

BSD

A Simple Script for Creating and Deleting Rolling ZFS Snapshots in FreeBSD

Here’s a simple little Bourne shell-compatible script I wrote to create and delete rolling ZFS snapshots on a small home server running the FreeBSD operating system. Sure there’s ports/packages available in FreeBSD to accomplish this, but there’s something to be said for keeping it simple and having one less piece of software to update and maintain.

As currently configured, the script recursively creates a daily snapshot of /pool_0/dataset_0. The name of each snapshot consists of the word “snap,” followed by the date and time the snapshot was taken (e.g., snap-202002102300). Snapshots are retained in pool_0/dataset_0/.zfs/snapshots. The script will then destroy any snapshot older that 90 days and log what its done to the file cronlog located in my home directory. A typical ~/cronlog entry looks like the following:

Using the script

To use the script, I save it as zfssnap.sh in ~/bin, where I keep most of my helper scripts, and make it executable:

Then I delegate some ZFS permissions to user iceflatline so snapshots can be created and destroyed without becoming the root user. However, this command is issued as the user root:

Note that I’ve set permissions at the zpool level, which means that all datasets under pool_0 will inherit these settings. Alternatively I could have applied the permissions just to dataset_0.

Then I make the snapshots retained in pool_0/dataset_0/.zfs/snapshots. Here too, the command must be issued as the user root:

Here again, I’ve applied applied this setting at the zpool level so when additional datasets are created in pool_0 they will inherit this setting. And here too, I could have applied this setting just to dataset_0.

Finally I configure a cronjob in the crontab for user iceflatline so that the script runs daily at 23:00:

If you’d like to use the script as is then simply modify the variable src_0 to reflect the name of your zpool and dataset. Else, modify the script to suite your needs.

Prefer to run the script more frequently than daily? Modify your cronjob. Here are couple of examples for running the script more frequently:

Don’t like the snapshot naming convention. No problem, just modify the variable snap_prefix.

Prefer to have more or less than 90 snapshots? Modify the retention variable.

Want to add other zpools and/or datasets? Add them to another variable (e.g., src_1), then modify the remainder of the script to recognize and take action on them.

Prefer to have the script log its output to a different location? Modify the log variable.

You get the idea.

Conclusion

There you have it. A simple way to create and destroy ZFS snapshots on a rolling basis under FreeBSD.

News

New Site Theme?

UPDATE: Okay, I think I like this theme. It’s called Noto Simple and as you can see it has a bright, fresh look with only minimum stylings. Works well on mobile devices too. Quite a departure from the dark theme that anchored this site for many years. Let me know if you encounter any issue with it.

Bear with me as I experiment with a new theme or two for the site.