Frequently asked questions regarding Synchronet on UNIX and Unix-like operating systems (e.g. Linux).
Question:
What flavors of Unix (and Unix-like operating systems) are supported?
Answer:
Currently there are four levels of support for Unix-like OSs.
Question:
What distributions of Linux are supported?
Answer:
Should work with any GNU/Linux-x86 or x64 distribution (e.g. RedHat, Debian, Slackware, Ubuntu, Gentoo, etc.).
Question:
64-bit?
Answer:
64-bit Linux (x64, x86_64, x86-64) distributions are supported.
Question:
The installer (e.g. Linux-install from sbbsunix.tgz) segfaults, crashes, or fails to get the file size of sbbs_src.tgz.
Answer:
This installer has known issues and is currently unsupported. Do not use
it. This installer (known to us as “sbbsinst”) may be revamped and re-released in the near future.
In the mean-time, follow the steps given in this document to download, build, install, and run Synchronet for Unix.
Question:
Are non-x86/x64 (Alpha, SPARC, 68k, PowerPC, etc) processors supported?
Answer:
Not currently. Synchronet assumes a little-endian processor. It *may* work
on other little-endian processors (e.g. Alpha), but hasn't been tested.
Question:
Where do I get Synchronet for Unix?
Answer:
See the step-by-step instructions here.
Question:
Will there be binary releases?
Answer:
Maybe. Linux is a particularly difficult “platform” to deliver consistently
compatible binaries for and unfortunately, it is the most popular Unix-like
operating system we currently support.
Question:
Can I mix Synchronet for Unix and Synchronet for Win32 or DOS or OS/2 nodes
on the same BBS?
Answer:
Yes. As long as all the nodes can access the same live data files (via LAN)
you can have as many instances of Synchronet on as many different platforms
as you wish.
Question:
Does Synchronet for Unix support external DOS programs/doors?
Answer:
Currently, only the FreeBSD build has doscmd support “built-in” (and this
“support” requires emulators/doscmd to be installed):
For FreeBSD, the path that is entered in the Start-up Directory is mapped as C:\ the current node directory is mapped as D:\ and the Synchronet root directory is mapped as E:\. When a DOS door is executed, a .doscmdrc is created in the node directory. Copying this file and using it to run doscmd in X11 mode while running the setup programs is the simplest way to configure the doors.
Other platforms can use DOSEMU or whatever is available for running DOS programs.
For running external DOS programs on Linux using DOSEMU, see dosemu for details.
Question:
What external programs/doors does Synchronet for Unix support?
Answer:
External programs can either use standard I/O (e.g. bash, pico, Lord/X,
PimpWars) or socket I/O (e.g. Synchronet XSDK doors).
Question:
Does Synchronet for Unix require X-Windows?
Answer:
No, Synchronet for Unix is currently a console-based application.
However, it does have an X-based character mode console now. The X11
headers (Part of the X11-devel package or something similar) are required
for this to work.
Question:
Are there any plans to make an X-Windows front-end for Synchronet?
Answer:
See gtkmonitor.
Question:
Can I use a different compiler (than GCC) to build Synchronet for *nix?
Answer:
Yes, currently Synchronet has successfully been built with GCC, ICC
(The Intel C Compiler), and Clang/LLVM. To specify an alternate compiler, add
CC=icc CXX=icpc to the gmake command lines where icc is the C compiler name
and icpc is the C++ compiler name. If you get errors during the build (not
warnings) please submit a bug report. If you are using a commercial compiler
other than ICC, we will probably be unable to help you without a copy of the
compiler.
Question:
I'm using SELinux and nothing works.
Answer:
Yes, you'll need to use chcon on each of the Synchronet shared objects (.so files):
chcon -t texrel_shlib_t /sbbs/exec/*.so
Question:
How much disk space do I need?
Answer:
A fresh install (as of Mar-2020) from source code, requires about 500MBytes of space.
Much of the space consumed is in the form of intermediate build files which may be removed after the build is complete if space is a concern.
Question:
What does the error Unknown terminal: pc3 displayed by some native external programs (e.g. pico) indicate?
Answer:
The error indicates that the value of your TERM environment variable (in the example case, pc3) is not a valid terminal type/capabilities name for your system.
The default value of the ExternalTermANSI key in your sbbs.ini file is pc3, and Synchronet uses the value of this key to set the TERM environment variable for child processes (external programs). If your *nix installation has a terminal type/capability with this name, then this terminal type might work for you (and your users) but there is a better option: to use the Synchronet ansi-bbs terminal capabilities set (created by Deuce). The configuration/installation instructions for the Synchronet ansi-bbs terminal capabilities set are covered in termcap.
Question:
Why do I get the GCC compilation warning:
the use of `tempnam' is dangerous, better use `mkstemp'
?
Answer:
This is not an error but a harmless warning. You can safely ignore it.
To elaborate, SBBSecho uses tempnam for a specific purpose, which mkstemp does not do. Additionally mkstemp is not available in all the C libraries for all the platforms for which Synchronet is built. The dangers of tempnam do not apply to SBBSecho's use of the function.
Question:
How do I work around SDL_main errors (e.g. No protocol specified followed by a segmentation fault) that prevent Synchronet applications (e.g. SCFG, EchoCFG, umonitor, etc.) built with SDL 1.2 from running?
$ /sbbs/exec/scfg No protocol specified No protocol specified No protocol specified Segmentation fault (core dumped)
Answer:
Double check that you can run X applications (e.g. xterm, xeyes) and if you cannot, you may need to grant X access to other user accounts with a command like:
xhost +SI:localuser:<username>
executed before switching to another user account (e.g. with su or sudo).
Work-arounds:
WITHOUT_SDL=1 on the make command-lines or in your localdefs.mk file)SDL_VIDEODRIVER environment variable to the value of dummy (e.g. EXPORT SDL_VIDEODRIVER=dummy) before executing the program
Question:
Why do my servers/services fail to recycle when I set the node-recycle flag (e.g. saving changes in SCFG) or when touching recycle semfiles?
Answer:
Servers will not recycle while they are in-use.
$ node rerun Synchronet Node Display/Control Utility v1.34 Node 1: User #1 reading messages via telnet (M) [R] Node 2: Waiting for connection [R] Node 3: Waiting for connection [R] Node 4: Waiting for connection [R] Node 5: Waiting for connection [R] Node 6: Waiting for connection [R] Node 7: Waiting for connection [R] Node 8: Waiting for connection [R]
Question:
What do the following warning-level log messages indicate?
Disabling Terminal Server recycle support Disabling FTP Server recycle support Disabling Web Server recycle support Disabling Mail Server recycle support Disabling Services recycle support
Answer:
Recycle support can be disabled manually be setting the NO_RECYCLE Options flag in one or more server sections of your sbbs.ini file.
The log warning messages above (“Disabling ... recycle support”) indicate that the BBS automatically set the NO_RECYCLE option flag because it was:
The solution is to remove the User and Group settings from the UNIX section of sbbs.ini and then follow the instructions here for running the BBS on Linux as a non-root user (if you haven't already).
Question:
Why am I seeing ERROR 24 (Too many open files) failures in my error log?
Answer:
Versions of Synchronet prior to v3.19c contained a bug with the JavaScript User class that could cause a leak of open file descriptors (concurrent opens of the data/user.dat file that were never closed). This bug, combined with a long-running webv4 events.ssjs issue that could cause a lot of instances of the User class to linger in the JavaScript heap (since fixed with a call to js.gc()), could cause “Too many open files” errors to occur.
Answer:
You need to increase your maximum number of open files.
Checking current open file limits
The most reliable way to determine your open file limit is to login to your BBS as a sysop, run the ;SHELL string command, and at the OS command line, issue the commands below. The hard limit is the systemwide limit, and the soft limit is one that a user can raise (up to the hard limit).
To view the soft limit: ulimit -Sn
To view the hard limit: ulimit -Hn
Another method that works on Linux is to search for line beginning with “Max open files” in the file /proc/$(pidof sbbs)/limits:
$ sudo grep "Max open files" /proc/$(pidof sbbs)/limits Max open files 10000 10000 files
If you start Synchronet with systemd
If you're using systemd to start sbbs, edit your service file (usually sbbs.service) by adding the following line in the [Service] section:
LimitNOFILE=10000
After adding the line, reload the service file from the command line using systemctl daemon-reload. Finally, restart Synchronet.
If you start Synchronet manually or with a shell script
If you start sbbs with a shell script, manually from the command line, or some other similar method, edit /etc/security/limits.conf to add the lines below.
To raise the soft limit for your Synchronet user, add this line:
yourBBSuser soft nofile 10000