Linux offers some great advantages when using Opensim. Linux lets your server take care of itself. Part 1 covers the basic usage of screen.
While Windows offer great performance and stability and the
basic memory consumption does not really count above 20 regions
anymore - there are 2 big advantages running opensim on Linux:
non-existent license costs and easy and
efficient automation.
Using the 'screen' command and other Linux standard command
line tools you can easily automate many Opensim maintenance
tasks.
All examples below are made as readable as possible. They are
a good start for experimenting and easy to adopt for a novice Linux
users. This means that they are not the most effective geek
versions.
I assume that you operate your server on the internet with the
latest patches, antivirus and a firewall in place.
In this series of articles we are going to cover some common
maintenance tasks: How and when to do a backup? How to check
wether a simulator is up and running? How to automatically
stop and restart your simulator to make a concistent
backup?
Basics
The example production server is using MONO on openSuSE
(Novell ist the main contributor to MONO and SuSE) 11.1.
The examples are based on openSusE, but they should work on
any other Linux as well.
For maintenance and customer interfaces I use
www.webmin.com and
NX-server/clients sometimes.
The automation is mostly based on bash as a shell, and on
common tools like grep and "screen".
screen
"Screen is a full-screen window manager that multiplexes
a physical terminal between several processes, typically
interactive shells" like the project website states. In
"windowsish" i would translate it as a "run as a service with
ability to switch to interactive mode and programaticly interact
with tasks" (citation from
gnu). briefly: it´s
very cool.
All my opensim instances (and more) typically run under
screen. I do start them as screen, I watch for screen
sessions running, I inject messages for the user in a region,
perform oar backups, gracefully shut down simulators and
more. if that sounds interesting, read on.
Starting Opensim with screen
On a 64bit system, we usualy start mono from the /bin
directory with "mono OpenSim.32BitLaunch.exe"
In screen, the same thing would be "screen -S
water -d -m mono OpenSim.32BitLaunch.exe", again from the /bin
directory while launching.
-S start a named session, easier to find and search for
-d start detached (in background)
-m ignore $STY variable, do create a new screen session
Now, scanning via ps -ef (or your preference), you see the
screen and the mono-Opensim processes.
Connecting to and leaving a screen
session
You know that you list files with "ls" - so it is easy to
remember that "screen -ls" does list all your (you as a user)
screens.
A typicall output looks like:
There are screens on:
9706.tropical2
(Detached)
9599.hypergridshark (Detached)
9675.citys (Detached)
9584.water (Detached)
.
.
17 Sockets in /var/run/screens/S-root.
If you want to connect to the screen session named "water",
you tell screen to reconnect to a detached session by
"screen -r INSTANCENAME" , e.g.
"screen -r water"
e voila - there you are.
-r reattach to the Instance
Now you can act just as in a usual Opensim instance started
directly from the bash command line.
If you want to leave this session, while it continues (detach
again) - use keyboard commands:
<CTRL-a> then <CTRL-d>
You are back in the CLI/shell again. With "screen -ls"
you will see that the process is still running.
Shut down a session
As our first an simple step to automated procedures, we
perrform a common task to shutdown the Opensim instance.
I usually do that periodically (using cron) before the daily
backup.
With "screen -S water -r -m -X quit" you tell screen
to
-S use the instancename following
-r reattach to the Instance
-m ignore $STY variable, do create a new screen
session
- X execute the following string, as it would be a command in
CLI
So we silently reconnect to a session and execute the command
"quit" in Opensim, wich shuts it down gracefully.
Note: use screen instance names that are unique. If you will
automate a watchdog, that checks for a a screen named "grep" - will
not helpt to much. :-) However, maybe watchdog is even more a
question of PID-files in unix, since we have them now.
I guess this gave a nice first impression. It gets a bit more
complex when sending more than just a single word - we will see how
to do that in the next article.
cheers,
Ralf
We recommend that you discuss this article on Think, but if you really want to you can leave a comment right here as well: