Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
howto:systemd [2020/01/31 12:04] – Clean-up. Provide download link to sbbs.service in CVS. Use wildcards in setcap command. digital manhowto:systemd [2022/05/07 20:25] – systemd shouldn't be capitalized. Added a section for people to find their existing service file. Minor formatting fix to "tweaks" section. Andre
Line 1: Line 1:
-====== Start Synchronet BBS from Systemd ======+====== Start Synchronet BBS from systemd ======
  
-If you run a modern GNU/Linux distribution, you will likely discover [[https://en.wikipedia.org/wiki/Systemd|Systemd]] is used as the init system (for starting and control system services/daemons).+If you run a modern GNU/Linux distribution, you will likely discover [[https://en.wikipedia.org/wiki/Systemd|systemd]] is used as the init system (for starting and control system services/daemons).
  
 In this case, instead of use the old SysV-style /etc/init.d/sbbs.service init script, you use a systemd services unit file: In this case, instead of use the old SysV-style /etc/init.d/sbbs.service init script, you use a systemd services unit file:
  
 Create and edit (or download from [[http://cvs.synchro.net/cgi-bin/viewcvs.cgi/*checkout*/install/systemd/sbbs.service|here]]) the following file (please correct your ExecStart path and User/Group as you need): Create and edit (or download from [[http://cvs.synchro.net/cgi-bin/viewcvs.cgi/*checkout*/install/systemd/sbbs.service|here]]) the following file (please correct your ExecStart path and User/Group as you need):
 +
 +===== Where is My Service File? =====
 +
 +If you are already running Synchronet from systemd but can't remember where the config file is, the following commands will help.
 +
 +''systemctl status'', then when viewing the file type ''/sbbs''. Note the service name (probably sbbs.service). ''q'' to quit back to the command line.
 +
 +Use that service name to return the path to the config file. Example: ''systemctl show -p FragmentPath sbbs.service''
 +
  
 ===== Ubuntu 16.04+ ===== ===== Ubuntu 16.04+ =====
Line 21: Line 30:
   Group=sbbs   Group=sbbs
   PermissionsStartOnly=true   PermissionsStartOnly=true
-  ExecStartPre=/sbin/setcap 'cap_net_bind_service=+ep' /sbbs/src/sbbs3/gcc.linux.*.exe.*/sbbs 
   ExecStart=/sbbs/exec/sbbs d   ExecStart=/sbbs/exec/sbbs d
   ExecReload=/bin/kill -HUP $MAINPID   ExecReload=/bin/kill -HUP $MAINPID
Line 37: Line 45:
    * **User/Group**. **Remove these** if you would like sbbs to start as root and then drop privileges to the User & Group configured in your sbbs.ini. Possibly remove **PermissionsStartOnly** and **ExecStartPre** as well, as they would be unnecessary.   If you leave these in, ensure the User/Group settings in sbbs.ini are commented out.    * **User/Group**. **Remove these** if you would like sbbs to start as root and then drop privileges to the User & Group configured in your sbbs.ini. Possibly remove **PermissionsStartOnly** and **ExecStartPre** as well, as they would be unnecessary.   If you leave these in, ensure the User/Group settings in sbbs.ini are commented out.
    * **PermissionsStartOnly**. This one tells systemd to execute ExecStartPre as root, but ExecStart as the user and group declared in User,Group.  Can be removed if you remove the User/Group lines.    * **PermissionsStartOnly**. This one tells systemd to execute ExecStartPre as root, but ExecStart as the user and group declared in User,Group.  Can be removed if you remove the User/Group lines.
-   * **ExecStartPre**. Capabilities are lost from the sbbs executable every time it is recompiled. It is possible to mitigate the effect by running setcap just before the daemon is ran. The binding won't fail anymore using this. Please notice you can't point to a symlink here). 
    * **ExecStart**. If you don't want to get syslog entries duplicated you will have to run SBBS in daemonized mode, so the "d" parameter is used. Syslog is implicit when daemonized, so there is no need for additional parameters.     * **ExecStart**. If you don't want to get syslog entries duplicated you will have to run SBBS in daemonized mode, so the "d" parameter is used. Syslog is implicit when daemonized, so there is no need for additional parameters. 
    * **RestartSec**. It's advisable to wait some secs before attempting restarting in case of failure, just to give some time for binding release.    * **RestartSec**. It's advisable to wait some secs before attempting restarting in case of failure, just to give some time for binding release.
Line 56: Line 63:
       Docs: man:sbbs       Docs: man:sbbs
    Process: 12364 ExecStart=/sbbs/exec/sbbs d (code=exited, status=0/SUCCESS)    Process: 12364 ExecStart=/sbbs/exec/sbbs d (code=exited, status=0/SUCCESS)
-   Process: 12356 ExecStartPre=/sbin/setcap cap_net_bind_service=+ep /sbbs/src/sbbs3/gcc.linux.x64.exe.release/sbbs (code=exited, status 
   Main PID: 12374 (sbbs)   Main PID: 12374 (sbbs)
      Tasks: 11      Tasks: 11
Line 70: Line 76:
   Dec 11 20:24:03 HISPAMSX sbbs[1226]: term Node 1 thread terminated (0 node threads remain, 71 clients served)   Dec 11 20:24:03 HISPAMSX sbbs[1226]: term Node 1 thread terminated (0 node threads remain, 71 clients served)
  
 +**NOTE**:\\
 +If you're running any kind of recent (last 2yrs+) systemd, to avoid the use of ''[[howto:linux_non-root|setcap]]'' to run 'sbbs' as a non-root user, just put this line in the ''[Service]'' section of your ''sbbs.service'' file:  ''**AmbientCapabilities=CAP_NET_BIND_SERVICE**''
 ===== Monitoring with Byobu (Tmux backend) ===== ===== Monitoring with Byobu (Tmux backend) =====
 You can have a text mode dashboard for monitoring and configuring your BBS realtime by using Byobu with Tmux or GNU Screen backends. If you are using the Tmux backend. The following configuration splits your screen in three panes: one for SBBS log, other for UMONITOR and a last one for SCFG. Please note that this configuration assumes SBBSCTRL variable is set and that access permissions to the needed files are set for the current user. You can have a text mode dashboard for monitoring and configuring your BBS realtime by using Byobu with Tmux or GNU Screen backends. If you are using the Tmux backend. The following configuration splits your screen in three panes: one for SBBS log, other for UMONITOR and a last one for SCFG. Please note that this configuration assumes SBBSCTRL variable is set and that access permissions to the needed files are set for the current user.
Line 122: Line 130:
  
  
-Finally, you must execute //systemd daemon-reload// for tell systemd te reload the unit file+Finally, you must execute //systemd daemon-reload// for tell systemd to reload the unit file
  
 Test your setup: Test your setup:
Line 172: Line 180:
  
 ===== Recommended Tweaks to the Service Section === ===== Recommended Tweaks to the Service Section ===
-Add these to the ''[Service]'' section:+Add these to the ''[Service]'' section of your service's config file:
  
 To increase the open file limit: To increase the open file limit:
-  LimitNOFILE=10000+<file sbbs.service> 
 +LimitNOFILE=10000 
 +</file>
  
 To allow core file generation (for crash/segfault debugging: To allow core file generation (for crash/segfault debugging:
-  LimitCORE=infinity+<file sbbs.service> 
 +LimitCORE=infinity 
 +</file>
  
 ===== See Also ===== ===== See Also =====
howto/systemd.txt · Last modified: 2022/11/30 22:00 by digital man
Back to top
CC Attribution 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0