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):

/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:

1. Put this file in /lib/systemd/system/
2. Run “systemctl enable sbbs”
3. 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) 

/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.

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

• howto index