m Montag, 26. November 2012, 20:36:47 schrieben Sie: > ----- Original Message ----- > > > From: Sascha Cunz <sascha...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development