Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Writing a Daemon on Windows/Linux

by hackdaddy (Hermit)
on Nov 10, 2005 at 09:33 UTC ( #507322=perlquestion: print w/replies, xml ) Need Help??

hackdaddy has asked for the wisdom of the Perl Monks concerning the following question:

I'm writing a daemon to send soap requests to a Apache web server running on Windows. If the soap requests return the appropriate XML string, I need to launch a child process/fork/etc to run and complete a task on the server from which the daemon is running.

It needs to be cross platform because some machines will be Linux.

Does anyone have any suggestions on which modules to use? Does anyone have any sample code of daemons?

Any assistance will be greatly appreciated.


Replies are listed 'Best First'.
Re: Writing a Daemon on Windows/Linux
by BUU (Prior) on Nov 10, 2005 at 10:05 UTC
    Here's a module that implements a daemon: AS the above mentioned, forking generally works on all major platforms, win32 is a little weird with regards to forks, it actually does threads instead, but that typically doesn't matter. In general a daemon just needs to fork itself in to the background, optionally changing it's process group and so forth and detaching from the current session. Functions for this are available in POSIX.

    In general this sounds pretty simple. Fork is extremely easy to use and, for the most part, portable enough.
Re: Writing a Daemon on Windows/Linux
by EvanCarroll (Chaplain) on Nov 10, 2005 at 09:50 UTC
    So your sending soap requests, *BUT*, your also recieving them, which means you will need a server, so maybe SOAP::Lite. Forking by nature is pretty cross platform; but, you might also want to check out Parallel::ForkManager.

    Evan Carroll
      I've been messing around with Parallel::ForkManager and DBI connections to a MySQL database. The database connections in the child processes were not thread-safe I suppose. Perl was crashing because of some nasty stuff going on with opening and closing the connection in the different child processes.

      After talking over the design with my boss, we decided that soap with XML messages would be a better and more robust design.

      Actually, I'm pretty impressed with soap. I haven't used it until now, but it's working out quite well.

      Now I am using soap to make calls into the Web Server and the cgi script will make the appropriate database connections and then return an XML message.
Re: Writing a Daemon on Windows/Linux
by BrowserUk (Patriarch) on Nov 10, 2005 at 13:08 UTC

    I'm afraid that I have to disagree with some others about using a POSIX-style daemon mechanism on Win32. It's pseudo-forks, (almost non existant) signal handling, and (crufty) handle duplication and socket handling are all sufficiently non-POSIX that it will require you to add special cases throughout your code to handle Win32 specific issues.

    Better to test $^O and put all your Win32 code into a separate place. It makes the writing/testing/debug/maintanence of both branches of the code easier and cleaner.

    It also will allow you to do something more win32-ish, like creating a service (see Win32::Daemon ).

    Unless it is just the documentation that is out of date, I'd be wary of Net::Daemon, it talks about using threads and perl 5.005, which means what are now termed 5005threads, which have been deprecated (for good reasons) for a very long time and have now "gone away" in the last 2 or 3 releases.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Writing a Daemon on Windows/Linux
by radiantmatrix (Parson) on Nov 10, 2005 at 14:57 UTC

    Having addressed this issue in my work before, I will tell you what I found to work exceedingly well.

    The process of creating a detached process is very different in Win32 and *NIX; but, all the rest of what you need to do is pretty platform independent.

    So, using modules like SOAP::Lite and Parallel::ForkManager, or perhaps the usual fork can be implemented easily in a platform-neutral way. Create your own module that contains all the code you need to actually make the daemon do its thing.

    Then, create a Perl script for each platform that sets up the daemon process in the platform-specific manner and then runs the logic inside your module. For *NIX, I've had excellent success with Proc::Daemon, and on Win32 Win32::Service has worked well. Each of these scripts will only be a few lines long, and since they share code via your module, you aren't creating a maintenance headache.

    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    "In any sufficiently large group of people, most are idiots" - Kaa's Law
Re: Writing a Daemon on Windows/Linux
by dtr (Scribe) on Nov 10, 2005 at 09:57 UTC

    Generally, forking processes is pretty platform dependent.

    Could you use perl's threads (called iThreads) for this? Have a look at "perldoc perlthrtut" to learn more about iThreads.

      Aren't threads somewhat still experimental in Perl? This is supposed to be a professional custom client-server solution that the company will depend on day and night.

      It needs to be available 24/7 with no nasty surprises.

      It kind of makes me cringe to use Windows. I prefer to run Perl in a Unix environment.

      Otherwise, I'll have to break out C++ to create the daemon.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://507322]
Approved by GrandFather
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (7)
As of 2022-05-25 14:11 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (90 votes). Check out past polls.