On 19/11/2016 01:07, Klemens.Morgenstern@gmx.net wrote:
I am also not sure, why this would be a C++ library and not just an install script. I.e. wouldn't the daemon be written in C++ but the installation wouldn't need to be done in C++ - I'm not sure what the benefit would be.
In Windows, installation of a service application is typically most conveniently done by the service application itself via running with /install parameter or similar. Of course, this requires running the application in a different security context from normal (typically the installer runs it with admin permissions for this purpose, and it is expected to install and then exit -- the normal Windows service manager then starts it, at the request of one end or the other). Sometimes this dual privilege/dual responsibility makes people nervous and they'd rather keep these tasks separate though. But there's no reason why it couldn't be an entirely separate "install helper" distributed with the application or just code in the install script entirely separate from the application. (And in the latter case, it's probably not C++.) In any case in Windows the install code doesn't start any processes itself (even starting the service automatically is just a request to the SCM API to start the service on your behalf), so this definitely doesn't belong with Boost.Process. In Linux it's a little different, and I don't think "sudo some_serviced --install" is a thing that ever happens; such things are left to the package management systems guided by INSTALL readme files. Instead the main task for the code is relaunching as a daemon (essentially just using a trick to disown your parent console), which is something the app does at runtime entirely unrelated to installation. There's also a wider range of service management systems (eg. classic initd vs. systemd vs. others), which encourages leaving things to the package manager. I'm not against having a multi-platform library that tries to hide some of these details, but I'm also not convinced it's a sensible goal, since the activities are so widely different between platforms. Perhaps focus on having separate libraries for each platform to handle the common tasks on that platform instead?