Synchronet v3.16c-Win32 (install) has been released (Aug-2015).

You can donate to the Synchronet project using PayPal.

UNIX Installation

You will likely need to build Synchronet from source code for your Unix/Linux distribution, version, and platform architecture.

Before attempting to install/build Synchronet, insure that the prerequisites are installed.

Creating the Synchronet Directory

You must create the directory where Synchronet will live. Some common locations would be your home directory (e.g. /home/you/sbbs) or the system root directory (e.g. /sbbs).

By default, Synchronet executables will look for files in the /sbbs/ctrl directory, so if you install Synchronet into a different directory you will need to either create a symbolic link in your root directory (e.g. ln -s /home/you/sbbs /) or set the SBBSCTRL environment variable accordingly.

The remaining steps assume that the current working directory is your Synchronet installation directory:

# pwd


If a specific step belows causes problems (e.g. displays an error message), click the highlighted text for more details including common causes of errors.

Note: If you intend on using dosemu on Linux (for running 16-bit DOS doors), add USE_DOSEMU=1 to the below make command-lines.


Choose a build method (using CVS or not):

Using CVS

Quick installation from CVS:

  1. # make install SYMLINK=1

If you want to build a stable release from CVS, specify a valid release tag on the make command-line (e.g. sbbs316c):

  1. # make install SYMLINK=1 CVSTAG=sbbs316c
  • Note: these commands will make and install a RELEASE build of the software. To make and install a DEBUG build instead, pass DEBUG=1 on the make command-lines.


Alternatively, if you don't have a working CVS client, you can use the following steps to install the latest nightly development build:

  1. # tar -xzf sbbs_src.tgz
  2. # tar -xzf sbbs_run.tgz
  3. # cd /sbbs/src/sbbs3; make RELEASE=1
  4. # cd /sbbs/src/sbbs3/scfg; make RELEASE=1
  5. # cd /sbbs/xtrn/sbj; make
  6. # cd /sbbs/xtrn/sbl; make
  7. # cd /sbbs/exec
  8. # ln -s ../src/sbbs3/gcc.*.exe.release/* .
  9. # ln -s ../src/sbbs3/scfg/gcc.*.exe.release/scfg* .
  10. # make

If you want to build a stable release, replace the archive filenames above with valid release filenames:

  1. replace sbbs_dev.tgz with ssrc316c.tgz
  2. replace sbbs_run.tgz with srun316c.tgz
Using System Libraries

On systems that are not properly supported by SpiderMonkey, you may be need to make use of a vendor supplied version. Doing so is not recommended or well supported, but it may be the only way to get Synchronet running on some platforms. The following steps have been reported to work on Debian Squeeze (6.0) armel (ARMv5te, EABI) on a Marvell Sheevaplug dev kit.

  1. # apt-get install libmozjs185-dev
  2. Add JSINCLUDE=/usr/include/js JSLIB=mozjs185 to your make command line

On OpenBSD 5.5-current on 64-bit UltraSPARC:

  1. # pkg_add -r spidermonkey-1.9
  2. # ln -s /usr/local/lib/ /usr/local/lib/
  3. Add JSINCLUDE=/usr/local/include/js to your make command line.


  • The following error indicates that you failed to either build baja or symlink or copy it into your exec directory:
  make: *** No rule to make target `bullseye.bin', needed by `all'.  Stop.
  • The following error indicates that you failed to install the libnspr4-dev prerequisite:
  configure: error: your don't have NSPR installed or your version is too old
  • Errors such as “C++ cannot create executables” and many others are generally caused by missing prerequisites.


Since both of the above installation methods create symlinks to (rather than copy) your Synchronet library and executable files from your Synchronet build directories to your Synchronet exec directory, you must not delete (or “clean”) your build directories or else Synchronet (e.g. sbbs) and its utilities will not run until you rebuild them.

Debug Builds

Both of the above build installation methods build a “release” (or non-debug) version of the Synchronet library and executable files. If you won't be using a debugger (e.g. gdb) to debug Synchronet (e.g. root-cause and report or fix bugs in the source code), then you probably should run the “release” binaries as they will be smaller and faster.

If you wish to build debug binaries, add DEBUG=1 to the make command-lines in the above steps.

Debug and release builds files are generated in separate output directories. If you created symlinks to your executables (i.e. specified SYMLINK=1 on the first make invocation) and switched between release and debug builds, you will need to remove or replace the symlinks in your Synchronet exec directory.

JavaScript Library

As of October 8th, 2011, we are including the complete SpiderMonkey (JavaScript-C) library 1.8.5 source code in the Synchronet CVS Repository (under 3rdp/dist) and the src/sbbs3/GNUmakefile will build it automatically. You should now not need to specify a JSLIB= value on your make command-lines.

JavaScript Issues for OpenBSD Users

Compiling of the 3rd party package providing mozilla's JavaScript support seems to need an extra flag passed to it, at least for OpenBSD 4.9-5.x running on i386. When doing the initial make, try it with EXTRA_JS_CONFIGURE_ARGS=–disable-tracejit to get the process a little further along.

Build System

The make-based build system is a complex and magical beast. Changing it's behaviour though environment variables such as CFLAGS or twiddling the various undocumented knobs is not supported. If you do fiddle with the knobs and something breaks, you will be expected to support yourself regarding these changes… ie: the answer you are likely to get from the devs is “don't do that then”. Partial documentation can be found here: options

Third Party Builds

Some third parties make unsupported tarballs available from their own sites. Using them is not recommended or supported. Whenever possible you should build yourself.

OS Platform Provided By Date Archive
Raspbian Wheezy Raspberry Pi tidux Feb, 2014 bltnex.tar.gz
Debian squeeze amd64 digital_man Every morning sbbs_dev.tgz sbbs_run.tgz


See nix for more details on configuring the Synchronet initialization file (ctrl/sbbs.ini) for Unix/Linux.


Choose one mode (Console or Daemon):

Console Mode

You can manually run the Synchronet sysop console (somewhat interactive, but not usually preferred):

Most of what is displayed in the console is not logged to disk in this mode.

You have some monitoring and control options from the console command prompt. Hit ? for a menu of available commands (e.g. Q to quit, stopping Synchronet).

Daemon Mode

You can install Synchronet to run as a daemon (background service, usually preferred).

You must be 'root' to install daemons on Unix/Linux.


  1. # cd /etc/init.d
  2. # chmod +x sbbs
  3. # /etc/init.d/sbbs start

See syslog, umonitor, gtkmonitor and node for details on options for monitoring the Synchronet daemon while it's running in the background:

# /etc/init.d/sbbs status
Synchronet BBS services status: [running]
PID(s): 25171
Red Hat

If using a Red Hat based Linux (e.g. Fedora), you may need to add the Synchronet system service to your startup configuration for the sbbs daemon to start automatically during system startup:

# chkconfig --add sbbs

If using a Debian based Linux, you should use either of the following methods to add the Synchronet system service to your startup configuration for the sbbs daemon to start automatically during system startup:

# insserv -v sbbs


# update-rc.d sbbs enable 2 3 4 5


1) Get the Synchronet service run script (init file) from here.

2) Copy the run script (sbbs) into your /usr/local/etc/rc.d directory

3) Set up the sbbs settings: In one of /etc/rc.conf, /etc/rc.conf.local, or /etc/rc.conf.d/sbbs, add the line:

 sbbs_enable=YES      # Required to run Synchronet

4) In one of the files from step three, add appropriate lines from the following (Defaults are shown here):

 sbbs_flags=""                        # Additional command-line flags
 sbbs_pidfile="/var/run/"     # Path of pid from your .ini
 sbbs_dir="/sbbs/"                    # Root sbbs path
                                      # The rest of the sbbs_*dir derive
                                      # from this be default
 sbbs_program="${sbbs_execdir}/sbbs"  # Synchronet binary
 sbbs_procname="${sbbs_program}"      # Process name as seen by ps(1)
 sbbs_shell="/bin/sh"                 # SHELL variable
 sbbs_user="root"                     # User to START sbbs as.  If this is
                                      # not root, you cannot bind low ports
 sbbs_group="wheel"                   # Group to start sbbs as

5) Start the Synchronet system service (FreeBSD 5.x+):

# /usr/local/etc/rc.d/sbbs start

Terminal Capabilities

As you may have noticed by now, most telnet clients designed for use with ANSI BBSes do not display full-screen Unix programs correctly. Included with Synchronet is a pair of terminal capability definition files that enable you to run native full-screen Unix programs and have the output displayed correctly in a standard ANSI-BBS terminal. These files are termcap and terminfo, located in your Synchronet install directory. Your system will use one or the other, and it won't hurt to install both. You will need to be logged in as root to install the files.

Installing the terminfo file

1) Get the Synchronet ANSI-BBS terminfo file from here.

2) Enter the command:

# tic terminfo

Installing the termcap file

1) Get the Synchronet ANSI-BBS termcap file from here.

2) Enter the command:

# cat termcap >> /etc/termcap

3) FreeBSD Only run the command:

# cap_mkdb -f /usr/share/misc/termcap /etc/termcap

Once the terminal capability files are installed, edit the ExternalTermANSI value in the [BBS] section of your sbbs.ini file to read:


Note: The default value of the ExternalTermANSI sbbs.ini key is pc3. If you get an error Unknown terminal: pc3 from external programs, it means that this key value has not been set to a valid terminal type.

Note: Once again, many Linux distros do not have a termcap. This is fine. You do NOT need to install the termcap-compat package. If termcap isn't installed, it means nothing uses it. Only if there is a termcap do you need to add the ansi-bbs termcap definition.

A note on SysOp paging

For most systems, the BBS must either have write access to the sound card via /dev/dsp, or run as root to page the SysOp. FreeBSD supports an alternative method which requires one of the following:

On FreeBSD 5.x and higher

One of:

  1. A custom kernel with the following option in the config device speaker
  2. The speaker module loaded by either:
    1. Running kldload speaker
    2. The line speaker_load=“YES” in /boot/loader.conf file

/dev/speaker should be read/writeable by the user the BBS runs as.


Updating/synchronizing the source code with the CVS repository:

1. Change to your Synchronet installation directory:

# cd /sbbs

2. Back-up your working exec directory:

# tar -czf exec.tgz exec

3. Get the latest changes from CVS:

# export 
# cvs update -d exec
# cvs update src 3rdp

4. Rebuild Synchronet and Baja modules:

  1. # cd /sbbs/src/sbbs3; make RELEASE=1
  2. # cd /sbbs/src/sbbs3/scfg; make RELEASE=1
  3. # cd /sbbs/exec; make

5. Update the exec directory organization:

  1. # /sbbs/exec/jsexec update.js

6. Shutdown and re-run sbbs:

  1. # /etc/init.d/sbbs restart

Clean Rebuild

Occasionally, you may need to perform a clean rebuild. A clean build can generally be achieved by first executing “make RELEASE=1 clean” in the src/sbbs3 directory before performing your normal make command-lines (step 4 above), but sometimes (rarely) the clean command will need to be executed in one or all of the following directories first (e.g. when dependent files are deprecated and removed from CVS):

  • src/comio
  • src/conio
  • src/smblib
  • src/uifc
  • src/xpdev

See Also

In Other Languages
Translations of this page:
QR Code
QR Code UNIX Installation (generated for current page)