[Development] Qt Playground - Updating Daemon/Service Support

[Sascha Cunz]

m Montag, 26. November 2012, 20:36:47 schrieben Sie:
> ----- Original Message -----
> 
> > From: Sascha Cunz <sascha-ml at babbelbox.org>
> > Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
> > 
> >>  All services/daemons must be able to interface with other processes:
> > Here, I almost agree :-)
> > 
> >>    (a)- a "client-process" can
> > 
> > "request-a-client-operation" to occur on that
> > 
> >>  service/daemon
> > 
> > But this is totally orthogonal to the application being a daemon/service.
> > To some daemons your application "talks" HTTP, SMTP, mysql-protocol or
> > whatever
> > others...
> > Why would someone writing a cron-alike daemon want to listen on some
> > QLocalSocket?
> 
> Kind of.
> 
> A daemon/service has two interfaces: (i) user/system-API oriented, and (ii)
> one internal.
> 
> The first presents the interface to the outside world on how to control the
> service. This interface needs to integrated into the system - e.g. Windows
> Service API, systemd, shell scripting, user query.
Right.

> However, this interface
> also needs to be able to talk to the daemonized process which has had its
> user-interface (e.g. Tty) removed from it. You can only do that using some
> form of communications - network port, message queues, etc.
But why would it want to do that? I mean: Is there a generic gain that is not 
already provided by the operating system itself?

> > > That is the task of:
> > - launchctl on Mac
> > - Service-Manager / "net start" / ServiceControlManager-API on Windows
> > - Init-Scripts (or interfaces to them) on Linux
> >   [This describtion meats OpenRC, Upstart, systemd and even SysVInit,
> > right?]

> yes, and we have to implement the interfaces to those. Each of those has a
> front end interface that must talk via IPC to a daemonized process in some
> form. Some form of IPC must be used.

Actually, I still don't get what you want to do with that IPC. And by the way: 
I didn't say, that I thought what QService<> is doing right now, was right. 
Instead I doubt that.

Just 2 examples:

To start or stop a service on Windows, you have 3 methods:
1. Via GUI: There's a service management application (nowadays launchable from 
TaskManager)
2. Via Command-Line: "net start" / "net stop"

Both of these are wrappers for:
3. "ServiceControlManager"-API, which is a RPC/IPC mechanism built into 
Windows itself that is esp. designed to do those kind of things.

The service registers itself with SCM and receives the commands you're talking 
about _from SCM_. The SCM takes care of "impersonating" the service correctly, 
etc.
See [1].

On linux, it is very common to "singal" daemons for actions like "stop" or 
"reload your config, please". Then the daemon-process itself acts upon that 
singal. I can't "kill -9" someone else's process, unless I'm root.

What current operating system forces you to tell your daemon via a 
QLocalSocket that it has to perform some administative operation?

Even if you were about to write a cross-platform Daemon-Controller tool, you 
should still not talk to the daemon directly, but rather to the infrastructure 
provided by the operating system.

Sascha

[1] http://msdn.microsoft.com/en-
us/library/windows/desktop/bb540476%28v=vs.85%29.aspx