Usage as a windows service

[bmappi]

Hello,

On Windows when creating a service:

@echo off
setlocal
set SERVICE_NAME=ModbusGateway
set DISPLAY_NAME=Modbus Server Service
set INSTALL_DIR=C:\ModbusGateway
set EXECUTABLE=%INSTALL_DIR%\omodsim.exe
set CONFIG_DIR=%INSTALL_DIR%\conf\TestConfig
set EXEC_CMD="%EXECUTABLE%" --config "%CONFIG_DIR%"

sc create "%SERVICE_NAME%" binPath= "%EXEC_CMD%" DisplayName= "%DISPLAY_NAME%" start= auto
sc start "%SERVICE_NAME%"

The executable does not reply in a manner that windows SCM expect for a service. Quick solution is to use things like NSSM but not ideal.

To work with Windows service, the main should detects if it's launched by the SCM (Service Control Manager), and runs in service mode.

I currently made an experimental version that supports it (using the --service flag): https://github.com/bmappi/OpenModSim/blob/main/omodsim/main.cpp#L152

C:\ModbusGateway\omodsim.exe --service --config C:\ModbusGateway\conf\TestConfig

My code is very bad, I am not c++ developer and just tried to make it work. The handler is limited and only supports running the server as subprocess (stopping / restarting won't work, also losing its child process won't start it again)

Also, it looks like there is a bug on windows (running on Windows 10 22H2) with command line arguments not displayed on the console. My fix was to use QMessageBox to show the text, but better would be hooking the parent console if present when using command line arguments.

Good software, reliable. Thank you for your good work.

[sanny32]

Hello @bmappi. Thank you for your interest in the application.

Also, it looks like there is a bug on windows (running on Windows 10 22H2) with command line arguments not displayed on the console

This is a feature of the application compiled for Windows as a /SUBSYSTEM:WINDOWS application. Thanks for the comment, I'll fix it in the next version.

On Windows when creating a service:

Why do you use application as service? Why not just add the app to startup? Initially, the application was not intended to work as a service.

[bmappi]

Hello @sanny32 and thanks for your reply.

I am currently testing it as a modbus server for production, and having it being able to be ran both as service (/background) and standalone graphical application brings an interesting way of configuring / debugging that no other modbus server have: It is possible to use it as an application to configure the server, debug possibly bad frame, and even do scripting (very good feature !)
Then, when it is ready, I export the "test configuration" and run the server in the background using --config. The only issue is that in an event of crash, I would like the application to be able to restart and reload the config, then start the server again. Services on windows provide that very helpful monitoring feature of "restarting a crashed application". Right now I start it as a scheduled task and ran a standalone watchdog to see if it is still running, but I hope it could be done better.
I can understand if you're not interested in such change, but I thought it may be an interesting feature that could match some use cases.

Thanks again,

[raspopov]

Making a Qt program into a service is not that difficult, either for Windows (as a Windows Service) or for Linux (as a systemd daemon). I've done this for Debian. But is it really necessary? After all, a simple restart of the program in case of a crash can be achieved using third-party utilities, such as “Restart on Crash” or even a simple script file.