Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^2: RFC: an(other) UNIX daemon module implementation

by mantager (Sexton)
on Jun 26, 2012 at 07:12 UTC ( #978344=note: print w/ replies, xml ) Need Help??


in reply to Re: RFC: an(other) UNIX daemon module implementation
in thread RFC: an(other) UNIX daemon module implementation

Handle natively command line parsing, allowing the developer to specify extra command line options she might expect, and provide easy access to such configuration

Getopt::Long?

Of course :)

Thanks Alexander,
this is interesting. I'll take a look at daemontools.


Comment on Re^2: RFC: an(other) UNIX daemon module implementation
Re^3: RFC: an(other) UNIX daemon module implementation
by pklausner (Scribe) on Jun 26, 2012 at 09:35 UTC
    daemontools come from primordial times when BSDs had just rc.local and SYSV bare init.d start stop scripts. I would recommend to reconsider your operating system's wheels. They are pretty round nowadays:
    • systemd for most Linuxes
    • upstart for Ubuntu
    • launchd for OSX
    • SMF for Solaris
    • even rc.d on *BSD and init.d elsewhere should be good enough for easy administration - notably the check/status, reload parameters
    I certainly would hate an application which came with its own service management scheme and which made me ferret out its own special way of telling me its status. Just because some purity rule says: no "mixing the daemon executable with its controlling script."

      Mmmm I didn't dig very deeply into daemontools, but it didn't seem somethig that mixed the daemon with the controlling script, although I may be mistaken (I just took a glance at it).
      Rather, it seems to be a framework to provide systemd-like capabilities to the system.

      systemd is likely to obsolete the concept of "daemon", since it takes care of all the work of launching an application in background.
      - I like it - I was glad when Fedora adopted it :)
      Unfortunately, I'm stuck on RHEL and CentOS 5/6 (you may read: support for Perl 5.8.8 required @_@)

      As an exercise, I almost completely wrote the module I was thinking about - I'm implementing the "tie the handles to logging" part, now. It's quite funny :)

      Cheers.

        Mmmm I didn't dig very deeply into daemontools, but it didn't seem somethig that mixed the daemon with the controlling script, although I may be mistaken (I just took a glance at it).
        Rather, it seems to be a framework to provide systemd-like capabilities to the system.

        Correct. Let me show how daemontools work on my little server at home:

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
      daemontools come from primordial times when BSDs had just rc.local and SYSV bare init.d start stop scripts.

      Also known as The Good Old Days. :-) I get a little annoyed with the way I keep running into new ways to start/stop/status processes on Linux systems. They used to be in rcX.d, then init.d, and now when I run one of those, it tells me to use something called service. Seems like I've seen a couple other methods over the years. No, I'm not going to seriously argue that throwing everything into rc.local was better, but....

      On daemontools: it does a lot more than init.d scripts. It supervises processes and restarts them if stopped, provides easy logging and automated rollover of logs, and more. Combined with ucspi-tcp utilities like tcpserver, you can take a Perl script that simply reads from STDIN and writes to STDOUT, run it from daemontools with a few lines of shell script, and turn it into a network daemon with user- and IP-based security, multiple connections, logging of errors, and restart on die. I don't know how many of those other services provide that, but it's pretty handy.

      I certainly would hate an application which came with its own service management scheme and which made me ferret out its own special way of telling me its status.

      Agreed. Apache always annoyed me that way, by having its own apachectl. Most distributions now wrap that in an rc/init script so you don't have to know about it, but it made it more of a hassle to supervise with a system of your own choosing.

      Aaron B.
      Available for small or large Perl jobs; see my home node.

        On daemontools: [...] Combined with ucspi-tcp utilities like tcpserver, you can take a Perl script that simply reads from STDIN and writes to STDOUT, run it from daemontools with a few lines of shell script, and turn it into a network daemon with user- and IP-based security, multiple connections, logging of errors, and restart on die. I don't know how many of those other services provide that, but it's pretty handy.

        You can do that with xinetd, too. Actually, you don't even need perl for simpler tasks, you may use a shell script :D

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://978344]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (7)
As of 2014-12-21 14:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (106 votes), past polls