Re: [boost] [process] daemon ideas

Subject: Re: [boost] [process] daemon ideas
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-11-20 22:18:29

On 19/11/2016 01:07, Klemens.Morgenstern_at_[hidden] 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?