Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Cannot launch perl packer binary from inetd

by fergal1 (Initiate)
on Dec 11, 2012 at 18:27 UTC ( #1008364=perlquestion: print w/replies, xml ) Need Help??
fergal1 has asked for the wisdom of the Perl Monks concerning the following question:

Hi, When I use perl packer to produce a binary version of any perl script, it does not launch from inetd. The binary may be launched from the command line just fine. The perl script itself may be launched from inetd just fine. Can anyone advise me on how to get this working? Any help would be appreciated.

My test perl script

#!/usr/bin/perl BEGIN { open STDERR, ">>/portal/test.log"; } use Data::Dumper; use Getopt::Std; printf STDERR "%s %s Hello World!\n", scalar localtime;

My inetd.conf entry

443 stream tcp nowait portal /portal/bin/

Perl packer usage

# pp --version PAR Packager, version 1.008 (PAR version 1.002) #pp -o testportal

Replies are listed 'Best First'.
Re: Cannot launch perl packer binary from inetd
by flexvault (Monsignor) on Dec 11, 2012 at 19:28 UTC

    Welcome fergal1,

    This isn't really a Perl problem! When you launch a script from the command line in *nix, the environmental variables have been set up via your login. When you launch a script from 'inetd' you must ensure that required environment is set up for the script to work.

    This would be the same problem with any language (C, C++, etc.). What you could do to find the problem is in your test script open a file and dump your %ENV with a foreach loop. Move that file to a backup name and then call the script from 'inetd' and then compare the two files (can use 'diff' under *nix). It could be different users, protection problem, etc.

    Good Luck!

    "Well done is better than well said." - Benjamin Franklin

      Thanks flexvault I will investigate this.

      The Perl script lanuches and runs perfectly from inetd. However, the PAR packager binary version doesn't run. See below when I poked inetd, it launched the binary program (testportal). The response suggests that I am not calling the program correctly. Any ideas why would perl packer change the usage of my script and how come I can call it from the command line? Is this something to do with pp not supporting daemon mode as advised by Old Gray Bear or something else? Any more wisdom would be appreciated.

      # nc 8080 Usage: testportal [ -Alib.par ] [ -Idir ] [ -Mmodule ] [ src.par ] [ p ] testportal [ -B|-b ] [-Ooutfile] src.par
Re: Cannot launch perl packer binary from inetd
by Old_Gray_Bear (Bishop) on Dec 11, 2012 at 19:12 UTC
    Are you sure that pp supports a daemon-mode? A quick scan through the Doc didn't turn up anything saying that it does. Did I miss something? I am still pretty much BC (before coffee)here.... Time for another cuppa

    I Go Back to Sleep, Now.


Re: Cannot launch perl packer binary from inetd
by Anonymous Monk on Dec 11, 2012 at 19:20 UTC
Re: Cannot launch perl packer binary from inetd
by flexvault (Monsignor) on Dec 13, 2012 at 18:24 UTC

    For a little *nix background on 'inetd':

      'inetd' is a daemon that waits on ports and then calls (fork) a program to process the requests. When the program completes, it goes away. It is not a daemon, 'inetd' is the daemon.

      Note: If your not using a *nix 'inetd', then what I just stated could be totally wrong.

    That said, you can have both. As an example, 'pop3' is an example of being able to perform both. 'pop3' can be called from 'inetd' or you can run 'pop3' as a daemon. What's the difference -- performance. Usually 'inetd' is used for low usage requirement and the daemon 'pop3' will usually outperform the 'inetd' version by a factor of 10 or more.

    So maybe you want to look at making your script to run as a 'daemon'. Depending on the volume, you may not need to use 'fork', since the operating system will queue the port request and you can just loop on servicing the port requests.

    I have never used 'pp', but have written 'daemon's in several different languages, including Perl. I believe the 'Perl Cookbook' has examples of both pre-forked and dynamically forked daemons. You will need to call your script at system startup, and remove the call from 'inetd'. Look for 'rc.local' and put the execution of your script in there. Make sure to use the full path.

    Hope this helps!

    Good Luck!

    "Well done is better than well said." - Benjamin Franklin

      SOLUTION FOUND - When I added the -d option to my command line, the resultant binary may be launched by inetd. Perldoc pp does not go into much detail on this option. But contrib/docs/where_is_it.txt gave me the clue to find the answer. Thanks Anonymous Monk.

      POST-MORTEM - I suspect that my problem was caused due to Perl being installed on the target machine. When I build with dependencies the binary does not launch correctly (perhaps due to a library ambiguity?). When I rebuild without dependencies, the library is loaded and my program runs.

      Thanks for your help guys!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1008364]
Front-paged by Arunbear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (13)
As of 2018-10-19 17:50 GMT
Find Nodes?
    Voting Booth?
    When I need money for a bigger acquisition, I usually ...

    Results (110 votes). Check out past polls.