Re: [PEPr] Proposal for System::Daemon

Of course. Some daemons may very well require an open socket and maybe even some (advanced) conversation over it. But not all daemons are network(server) oriented. How about: - a logparser that stores results in MySQL - a website statistics generator - a video->flv converter - a database denormalizer/optimizer - an SMS daemon that reads messages from a database queue and uses XML over http to send it to your provider's gateway I could go on, but it's really up to you what to build with it. These kinds of applications however, would like to run in your server's background but do not necessarily require sockets for interaction. Input resulting in action may often come from changes in the filesystem or a table in your database. Like you say, there has to be some basic way to communicate with the daemon. What I think you're refering to is inter-process communication (correct me if you're not): You must be able to tell it to stop, start, reload a configuration file, or start a specific procedure, without having to (ab)use MySQL, sockets or your filesystem as a carrier. How do you do this once your program lives in the background. On POSIX systems, this is commonly done by sending signals. To help you send & interpret these signals, the proposed System_Daemon class comes with methods to: - write a startup & shutdown script (/etc/init.d/yourapp <start|stop|reload>) Run this script with a parameter from the terminal to send a signal to your background program. currently only debian/ubuntu supported - handle the common signals for you. e.g. SIGHUP - overrule the default signal handlers with your own (as of 0.2 thanks to input by Joe Stump). This way your own functions are called whenever a specific signal is received. For more info on signals: http://en.wikipedia.org/wiki/Signal_%28computing%29 I hope this answers your questions. I would be happy to provide additional info if needed. Kind regards -- Kevin van Zonneveld Work | http://www.true.nl/ About | http://kevin.vanzonneveld.net/ On Mon, May 5, 2008 at 2:54 PM, Dmitri <email12@sharedlog.com> wrote: > OK. But what do you mean by 'requires to open a port'? > I mean, how are you going to communicate with a daemon? > I am not really an expert in this area, but I assume there must be a way to > send and receive the data from the daemon, and it's either via tcp port or > unix socket. > > > > Kevin van Zonneveld wrote: > > > > I could be wrong but I believe Net_Server > > - requires you to open an port, not all daemons want to do that > > - and includes a lot of 'socket-oriented' code > > - gives you limited control over the 'daemonization' (sighandlers, etc) > > - provides limited OS integration (logging, generating startup files) > > > > These are all points that System_Daemon will focus on. There isn't a > > lot of shared code or logic between the two packages and this is > > mostly because the focus of System_Daemon lays on the daemon itself, > > and not specifically building network servers. It basically should > > allow you to build any kind of application on top of it's foundation. > > > > -- > > Kevin van Zonneveld > > Work | http://www.true.nl/ > > About | http://kevin.vanzonneveld.net/ > > > > > > > > > > -- > > Open Source ALL content management > with streaming video > http://wiki.sharedlog.com > > >