[process] daemon ideas
I am not sure if [process] is the right library, but I am thinking about building something to manage daemon install/uninstall across platforms, for example Windows's service, OS X's launchd, systemd, and SysV init. Every operating system offers some way to launch a daemon at boot, and also the ability to stop, recover, etc. The issue is they all do it slightly differently, unlike having a common main(). My thinking is to provide a thin layer for install/remove and service notification. I have looked at Boost.Application, but it's lacking install/uninstall, and also seems overly complicated. Thoughts? Thanks, -Eric
On 18 November 2016 at 08:08, Dracon Pern <draconpern@hotmail.com> wrote:
I am not sure if [process] is the right library, but I am thinking about building something to manage daemon install/uninstall across platforms, for example Windows's service, OS X's launchd, systemd, and SysV init. Every operating system offers some way to launch a daemon at boot, and also the ability to stop, recover, etc. The issue is they all do it slightly differently, unlike having a common main(). My thinking is to provide a thin layer for install/remove and service notification. I have looked at Boost.Application, but it's lacking install/uninstall, and also seems overly complicated.
Thoughts?
Here are mine: 1. The feature seems interesting to me. 2. I'm not sure if it should be in Boost.Process, maybe it should just depend on it? I guess it depends a lot on what the implementation needs. 3. I think there was an effort from the Boost.Application proposal to do the same thing. At the time Boost.Application was split into small libraries, and IIRC some of them are now in Boost. So basically there was interest in the daemon part of the project too. Joël Lamotte
Thanks,
-Eric
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
I am not sure if [process] is the right library, but I am thinking about building something to manage daemon install/uninstall across platforms, for example Windows's service, OS X's launchd, systemd, and SysV init. Every operating system offers some way to launch a daemon at boot, and also the ability to stop, recover, etc. The issue is they all do it slightly differently, unlike having a common main(). My thinking is to provide a thin layer for install/remove and service notification. I have looked at Boost.Application, but it's lacking install/uninstall, and also seems overly complicated.
Thoughts?
Boost.Process is definitely the wrong library for that, it is more about launching processes, then being a process; the latter would be boost.application. 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. But I do think an application approach would be the right one for this problem; be it part of boost.application or not. Probably the simplest solution would be, that the library already has the different entry points, and you need to add functions, similar to main, though they might be called "recover", "start", "stop". I don't know how active the development of boost.application is, but maybe you can help there and add a daemon-feature; or you build your own version of that. If I personally see a very complicated library, I mostly get cautious, because I might be underestimating the complexity of a problem.
Here are mine:
1. The feature seems interesting to me. 2. I'm not sure if it should be in Boost.Process, maybe it should just depend on it? I guess it depends a lot on what the implementation needs.
I'll even add features regarding process creation if they are needed for this and fit in the scope of process.
3. I think there was an effort from the Boost.Application proposal to do the same thing. At the time Boost.Application was split into small libraries, and IIRC some of them are now in Boost. So basically there was interest in the daemon part of the project too.
You are in fact correct, Boost.Dll was taken from boost.application.
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?
participants (4)
-
Dracon Pern -
Gavin Lambert -
Klaim - Joël Lamotte -
Klemens.Morgenstern＠gmx.net