railcontrol for Debian --------------------- !!! WARNING !!! BE AWARE, ONCE RailControl IS RUNNING, EVERY USER AND COMPUTER IN THE SAME NETWORK GAINS ACCESS TO CONTROL AND DAMAGE YOUR ROLLING STOCK AND LAYOUT! IT IS YOUR RESPONSIBILITY TO SET UP A FIREWALL AND/OR TAKE OTHER MEASURES TO BLOCK MALICIOUS PERSONS/COMPUTERS! The systemd service for RailControl is disabled by default because of the above warning. To enable it: 1. edit /etc/railcontrol.conf to your needs and 2. execute (as root): systemctl enable --now railcontrol.service To disable the system service: systemctl disable --now railcontrol.service NOTE: When you enable the Debian systemd service, the top left button 'Exit RailControl' will actually restart RailControl, because the service file is configured to treat the regular exit and immediately starts the railcontrol binary again. Your Debian package maintainer decided to do so, because that's a convenient way to reconnect RailControl to a digital command station since RailControl does not reconnect on its own. That limitation is known upstream. To actually stop RailControl, execute (as root): systemctl stop railcontrol.service To start it again, execute (as root): systemctl start railcontrol.service The systemd service is executed at high priority to keep latency low and keep RailControl responsive for, e.g., emergency stops. This does not guarantee things can go wrong, though! Respective options in railcontrol.service are: […] CPUWeight=10000 Nice=-20 IOSchedulingClass=realtime IOSchedulingPriority=0 […] If you prefer to run RailControl as a non-system user, e.g., your own user, please keep these limitations in mind: Known limitation 1: If you consider to start and stop railcontrol by a systemd service, there's an issue with stdin being /dev/null inside a systemd service environment. Workaround: Add the --daemonize option to railcontrol, this will stop it trying to read from /dev/stdin. […] [Service] ExecStart=/usr/bin/railcontrol --daemonize […] Type=forking […] Known limitation 2: Prepending paths to in 'dbfilename = ' breaks the cleanup of option 'dbkeepbackups'. Workaround: Do not prepand any path to 'dbfilename'. Set a working directory for the process where the database file (and also log file) will be kept. Add the WorkingDirectory= option to a systemd service file as one possible solution: […] [Service] WorkingDirectory=/home/myuser/railcontrol ExecStart=/usr/bin/railcontrol --daemonize […] Type=forking […] Debian specific dynamic linking: While the source package of railcontrol includes code copies of SQLite and zlib (details are documented in README.source), the binary package does NOT include those. The binary package is linked against the system libsqlite and system zlib1g packages. -- Bruno Kleinert Thu, 27 Nov 2025 10:57:12 +0100