Boost logo

Boost :

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?

Boost list run by bdawes at, gregod at, cpdaniel at, john at