Set Up and Run SmokeDetector

Setting Up SmokeDetector

Basic setup

To set up SmokeDetector (SD), please execute the following commands:

git clone
cd SmokeDetector
git checkout deploy
sudo pip3 install -r requirements.txt --upgrade
pip3 install --user -r user_requirements.txt --upgrade

Next, copy config.sample to a new file called config, and edit the values required. If you are going to be running this SmokeDetector instance as a normal SD instance with metasmoke, see the “config” file with MS below.

You should now be able to run SmokeDetector.

Running SmokeDetector with metasmoke

You will need a keybase account. You will also need to have the “smoke detector runner” role on metasmoke (MS). Contact an MS admin to request the role. When given the role, you should separately be added to the “charcoal” channel on keybase.

The “config” file with MS

In the files section for the keybase “charcoal” channel, there is a “config” file. You should use that config file as a basis for the “config” file you use in your “SmokeDetector” directory.

When testing: use a “rooms_custom.yml” file

If a file “rooms_custom.yml” exists in the SD directory, then it will be used instead of the “rooms.yml” file. If you are not running a full SD instance, which is reporting into Charcoal HQ and all other rooms, you will need to create a “rooms_custom.yml” which describes the rooms in which you want SD to be reporting and accepting commands. For more information about the format used in “rooms.yml” and “rooms_custom.yml”, please see: Rooms configuration.

Run SmokeDetector

At this point, you should be able to run SmokeDetector using the instructions below.

Setting up an AWS EC2 linux instance for SmokeDetector

Using a AWS EC2 instance can be a quick way to get an SD instance up and running. Based on reports from @iBug in chat, a T2.micro instance, what’s available from the AWS Free Tier for 12 months, doesn’t have enough CPU credits, at 6/hour, for the instance to be the active SD instance full-time. Brief testing with a T3.micro, 12 CPU credits/hour, indicated that it’s not sufficient to run SD full-time without additional CPU charges. It’s expected that a T3.small, 24 CPU credits/hour, should be sufficient for a full-time active SD instance. However, a T2.micro instance does appear to be enough for SD to run as a standby instance to fill in on an irregular basis without CPU charges, assuming it’s not running for more than a couple/few hours. An additional note is that SD on the AWS Linux AMI described below did report some out of memory errors when running on a T3.micro (1GB) without any swap configured. On the other hand, SD functions on a AWS Lightsail instance with 512MB RAM and 2GB swap configured, but that Lightsail instance doesn’t have enough CPU credits to operate SD for more than a few hours (and more cannot be purchased). On yet another hand, a t4g.nano, which has the same 512MB of RAM and 2GB of swap, but 2 vCPU compared to 1 vCPU for the low-end Lightsail, can be configured in unlimited modewith respect to CPU Credit usage, so can run SD indefinitely, just with potential substantial CPU credit charges if running full-time. The T4g.nano can also be significantly less expensive (~50%) than the lowest-end Lightsail, if run as a standby SD instance and the T4g.nano has been purchased as a reserved instance. [Note: the numbers for needed CPU credits mentioned above for T2 and T3 instances are old information. SD’s code changed in 2022-05 which should have notably lowered the overall CPU usage and the above comparisons for T2 and T3 have not been updated.]

To set-up a AWS EC2 instance for SD you can do the following:

Running SmokeDetector

To run, use python3, or python3 standby (preferably in a daemon-able mode, like a screen session). You can also use python3, but then SmokeDetector will be shut down after 6 hours; when running from, will automatically be restarted. (This is to be sure that closed WebSockets, if any, are reopened.) is the controlling Python code for SmokeDetector. It runs, which is the SD instance, in a subprocess and restarts the SD instance when it stops. may stop as the result of various chat !!/ commands, or do to errors. The syntax for is:

python3 [standby] [--loglevel=(debug|info|warning|error)] [no_se_activity_scan] [no_deletion_watcher] [no_edit_watcher]

Portions of this page were taken from