in reply to daemon with Perl on Linux

Looking at the source of Proc::Deamon, it actually binds STDIN STDOUT and STDERR to /dev/null, so none of them will be bound to your terminal. It also uses fork() and POSIX::setsid() which should ensure that the process is completely disconnected from the terminal in all other ways. (update: note that this is more or less exactly what a daemon IS. if you don't want this behaviour, you probably don't want to run your code as a daemon at all)

Daemons usually don't read anything from STDIN anyway (since they're supposed to be run completely in the background). Is there a reason you want to use STDIN to read from a socket instead of opening the socket in the daemon process?

It may make sense to put the "main code" in a separate module (see perlmod) for two reasons: one, so you can logically separate the daemon setup code from the processing code (i.e. just to make it easy to find the code you want and ignore the code you're not currently interested in); and two, if you put the processing code in a module you can use that same processing code in a program that doesn't act as a daemon (for instance, when testing the processing code, you can call it from a simple test script that gives output to STDOUT).

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Replies are listed 'Best First'.
Re^2: daemon with Perl on Linux
by rimvydazas (Novice) on Nov 29, 2007 at 18:15 UTC
    OK, now I am confused. When script is listening for the data on the socket, isn't STDIN whatever script receives from that socket? If so, then whenever I make the script to run as a daemon, I won't be able to receive anything on the socket since STDIN will be detached. Am I right? What I have is a script listening for the data on the socket, and I want that script to run in the background all the time and process whatever I get from that socket. By the way, how should I enable this daemon to run at startup? Is it enough just to add it to one of startup files, or should I use runlevel folders?... Thanks for the help.
[reply]
      STDIN is the name for one of the 3 standard file handles that a process inherits from its parent process. If you start a program from the command line without input redirection, STDIN is bound to the terminal, so that anything that's typed in at the terminal is delivered to the program via its STDIN handle.

      But you can also start programs with STDIN bound to something else: 

      $ my-program < a-file
# or
$ some-program | some-other-program

      [download]
      etc.

      In general when you open a socket you get/use a new filehandle especially for that socket, since even though it's possible to re-open STDIN in some other way later (through a socket or file or whatever) that would IMO just be confusing.

      Though most unix systems have a fairly similar ways to deal with startup/shutdown scripts through various runlevel files etc, the differences in how to administrate those files easily are different enough that you should probably just look up your system's documentation.

      If you want to become better informed about all these issues, I recommend Advanced Programming in the UNIX Environment (2nd edition).

[reply]
[d/l]

In Section Seekers of Perl Wisdom