This is an old revision of the document!
Table of Contents
Start Synchronet BBS from Systemd
If you run modern GNU/Linux distributions, you can found Systemd as init system (like Debian, Fedora and others).
Instead of use the old /etc/init.d/sbbs.service init script, you can create a systemd services unit file:
Create and edit the follow files (please correct your ExecStart path and User/Group as you need):
Ubuntu 16.04+
/lib/systemd/system/sbbs.service
[Unit] Description=Synchronet BBS service Documentation=man:sbbs After=syslog.target network.target [Service] Environment=SBBSROOT=/sbbs SBBSCTRL=/sbbs/ctrl User=sbbs Group=sbbs PermissionsStartOnly=true ExecStartPre=/sbin/setcap 'cap_net_bind_service=+ep' /sbbs/src/sbbs3/gcc.linux.x64.exe.release/sbbs ExecStart=/sbbs/exec/sbbs nd syslog ExecReload=/bin/kill -HUP $MAINPID StandardInput=null StandardOutput=null Restart=on-failure RestartSec=30 [Install] WantedBy=multi-user.target
Some points in this config:
- After. If you are using syslog with sbbs, so it is nice to put that requirement before systemd tries to launch sbbs.
- Environment. In order to avoid having multiple files, you can embed the variables inside the service file.
- PermissionsStartOnly. This one tells systemd to execute ExecStartPre asroot, but ExecStart as the user and group declared in User,Group.
- ExecStartPre. For some weird reason, capabilities are frequently lost from the sbbs executable. It is possible to mitigate the effect by running setcap just before the daemon is ran. The binding won't fail anymore using this.
- ExecStart. It's actually more useful to run sbbs without daemonize under systemd, in contrast to the SysV way, so the “nd” parameter is useful. However this will prevent using the syslog, so the parameter is added. Please notice you can't point a symlink here, so modify the architecture directory to the right path (gcc.linux.x64.exe.release or gcc.linux.exe.release).
- StandardInput/StandardOutput. For some reason, systemd was displaying control characters from the sbbs logging, making the logs annoying to read and systemd reporting “blob data”. It looks like it had something to do with the I/O treatment systemd does to the logging. Disabling it led sbbs logging playing nice with systemd journal, so null to them.
- RestartSec. It's advisable to wait some secs before attempting restarting in case of failure, just to give some time for binding release.
Installation instructions:
- Put this file in /lib/systemd/system/
- Run “systemctl enable sbbs”
- sbbs will be executed at startup and systemd will follow his execution health.
Running systemctl status sbbs will show:
● sbbs.service - Synchronet BBS service Loaded: loaded (/lib/systemd/system/sbbs.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2016-12-11 16:41:21 CET; 1h 42min ago Docs: man:sbbs Main PID: 1226 (sbbs) Tasks: 19 Memory: 94.0M CPU: 1min 38.596s CGroup: /system.slice/sbbs.service └─1226 /sbbs/exec/sbbs nd syslog Dec 11 18:23:25 HISPAMSX sbbs[1226]: term Node 1 Telnet ------- [----------] Dec 11 18:23:25 HISPAMSX sbbs[1226]: 12/11 18:23:25 term Node 1 Telnet -------- [----------] Dec 11 18:23:31 HISPAMSX sbbs[1226]: term Node 1 Terminal not detected, reducing inactivity hang-up timeout to 75 seconds Dec 11 18:23:31 HISPAMSX sbbs[1226]: 12/11 18:23:31 term Node 1 Terminal not detected, reducing inactivity hang-up timeout to 75 seconds Dec 11 18:23:36 HISPAMSX sbbs[1226]: term Node 1 Unknown User 'Enable' Dec 11 18:23:36 HISPAMSX sbbs[1226]: 12/11 18:23:36 term Node 1 Unknown User 'Enable' Dec 11 18:24:02 HISPAMSX sbbs[1226]: term Node 1 disconnected Dec 11 18:24:02 HISPAMSX sbbs[1226]: 12/11 18:24:02 term Node 1 disconnected Dec 11 18:24:03 HISPAMSX sbbs[1226]: term Node 1 thread terminated (0 node threads remain, 71 clients served) Dec 11 18:24:03 HISPAMSX sbbs[1226]: 12/11 18:24:03 term Node 1 thread terminated (0 node threads remain, 71 clients served)
Debian
/etc/default/sbbs
SBBSCTRL=/sbbs/ctrl
/etc/systemd/system/sbbs.service
[Unit] Description=Synchronet BBS Documentation=man:sbbs After=network.target [Service] Restart=on-failure EnvironmentFile=-/etc/default/sbbs ExecStart=/sbbs/exec/sbbs nd ExecReload=/bin/kill -HUP $MAINPID User=root Group=root [Install] WantedBy=multi-user.target
Finally, you must execute systemd daemon-reload for tell systemd te reload the unit file
Test your setup:
# systemctl status sbbs ● sbbs.service - Synchronet BBS Loaded: loaded (/etc/systemd/system/sbbs.service; enabled) Active: active (running) since lun 2016-11-21 14:39:53 ART; 24min ago Docs: man:sbbs Process: 14393 ExecStart=/sbbs/exec/sbbs nd (code=exited, status=0/SUCCESS) Main PID: 14393 (sbbs) CGroup: /system.slice/sbbs.service └─14393 /sbbs/exec/sbbs nd nov 21 14:39:53 scarlet systemd[1]: Started Synchronet BBS.
Debian (alternative using tmux)
You can use Tmux to still the Synchronet BBS console running on a screen that can be attached when you need
/etc/default/sbbs
SBBSCTRL=/sbbs/ctrl
/etc/systemd/system/sbbs.service
[Unit] Description=Synchronet BBS Documentation=man:sbbs After=network.target [Service] Restart=on-failure Type=forking KillMode=none EnvironmentFile=-/etc/default/sbbs ExecStart=/usr/bin/tmux new-session -d -s sbbs '/sbbs/exec/sbbs nd' ExecStop=/usr/bin/tmux send-keys -t sbbs 'q' C-m 'exit' C-m User=root Group=root [Install] WantedBy=multi-user.target
Using tmux, Synchronet start in a session (called sbbs), you can attach to the running console using tmux attach -t sbbs