Perl process as a unix background process

[gbostock]

I'm experiencing some strange behavior with a certain perl program
when trying to run it as a unix background process. This process runs
with no problems at the terminal.
When I do:
(prompt)$myperl.pl &

The process starts running, output comes to the terminal but the
prompt doesn't come back. If there is any input at the terminal a
message appears saying that the process has stopped.

If I do:
(prompt)$ nohup myperl.pl &

the same thing happens

If I do:
(prompt)$myother.pl &

then I get the prompt back and the process runs in the background just
fine and continues when I use the terminal as usual.

So the question is: Does anybody have any idea what could be in the
myperl.pl that could prevent it from running in the background?

Please don't ask me to post the code as it is proprietary. If you need
to see the code you're probably just guessing at what could be the
problem anyway. There is a huge difference between myperl.pl and
myother.pl so it's not just a matter of spotting the diference. I'm
just hoping that some one has seen this sort of thing before and knows
what causes it.I'm not new to perl or unix and I've never seen
anything like this. What could be in the perl code to prevent it from
running in the background?

 

[smallpond]

I'm experiencing some strange behavior with a certain perl program
when trying to run it as a unix background process. This process runs
with no problems at the terminal.
When I do:
(prompt)$myperl.pl &

The process starts running, output comes to the terminal but the
prompt doesn't come back. If there is any input at the terminal a
message appears saying that the process has stopped.

If I do:
(prompt)$ nohup myperl.pl &

the same thing happens

If I do:
(prompt)$myother.pl &

then I get the prompt back and the process runs in the background just
fine and continues when I use the terminal as usual.

So the question is: Does anybody have any idea what could be in the
myperl.pl that could prevent it from running in the background?

Please don't ask me to post the code as it is proprietary. If you need
to see the code you're probably just guessing at what could be the
problem anyway. There is a huge difference between myperl.pl and
myother.pl so it's not just a matter of spotting the diference. I'm
just hoping that some one has seen this sort of thing before and knows
what causes it.I'm not new to perl or unix and I've never seen
anything like this. What could be in the perl code to prevent it from
running in the background?

Important information that you left out:
- what shell are you running?
- did you write this code or someone else?
- what flavor of unix?

This sounds similar to delayed suspend mode in bash.

 

[John Kelly]

I'm experiencing some strange behavior with a certain perl program
when trying to run it as a unix background process.

Does anybody have any idea what could be in the myperl.pl that could
prevent it from running in the background?

Please don't ask me to post the code as it is proprietary.

No idea. But for fun, you could try:

The daemon helper, a small C program with a simple interface and a
liberal license. I use daemon helper for starting perl and bash
scripts, to read fifos fed by syslog. They block on read until syslog
provides data to work on. They never end, and need help to start as
"daemons."

But that's just one example. There are many other potential uses for
the daemon helper.

dh is its name; a natural companion to sh.

Hope you find it useful.

ftp://ftp.isp2dial.com/users/jak/src/dh/

 

[J. Gleixner]

I'm experiencing some strange behavior with a certain perl program
when trying to run it as a unix background process. This process runs
with no problems at the terminal.
When I do:
(prompt)$myperl.pl &

The process starts running, output comes to the terminal but the
prompt doesn't come back. If there is any input at the terminal a
message appears saying that the process has stopped.

If I do:
(prompt)$ nohup myperl.pl &

the same thing happens

If I do:
(prompt)$myother.pl &

then I get the prompt back and the process runs in the background just
fine and continues when I use the terminal as usual.

So the question is: Does anybody have any idea what could be in the
myperl.pl that could prevent it from running in the background?

Possibly it's reading from STDIN.

Please don't ask me to post the code as it is proprietary.

Instead, you could comment out large chunks of your code to
narrow down where it might occur. Once you narrow it down
to the particular line(s), then you can post your short example.

If you need
to see the code you're probably just guessing at what could be the
problem anyway. [...]

Amazing..

I'll let you guess as to how to provide the data to your process,
since you don't need to see the code.

 

[gbostock]

Important information that you left out:
  - what shell are you running?

bash. I've always been a ksh guy and I'm just getting going on bash
because I figured it was about time. How much different can bash be?

  - did you write this code or someone else?

Someone else did about a third of it, but that was the original third.
I checked with him and he can't explain what I'm seeing.

  - what flavor of unix? linux


This sounds similar to delayed suspend mode in bash.

Maybe you could elaborate on how that could be affected by the perl
process? I did a brief search on that and while it sounds related, I
don't know how the perl process could be sending ctl-z or ctl-y to the
shell.

Thanks.

- Hide quoted text -

 

[gbostock]

Possibly it's reading from STDIN.

Nope, it reads from files, but the problem manifests before it gets to
the file read.

Instead, you could comment out large chunks of your code to
narrow down where it might occur.  Once you narrow it down
to the particular line(s), then you can post your short example.

Narrow it down on what basis? Guessing?

If you need
to see the code you're probably just guessing at what could be the
problem anyway. [...]

Amazing..

I'll let you guess as to how to provide the data to your process,
since you don't need to see the code.

Object Oriented!?!?!? ;-)

- Hide quoted text -

 

[gbostock]

No idea.  But for fun, you could try:

The daemon helper, a small C program with a simple interface and a
liberal license.  I use daemon helper for starting perl and bash
scripts, to read fifos fed by syslog.  They block on read until syslog
provides data to work on.  They never end, and need help to start as
"daemons."

But that's just one example.  There are many other potential uses for
the daemon helper.

dh is its name; a natural companion to sh.

Hope you find it useful.

ftp://ftp.isp2dial.com/users/jak/src/dh/

It probably would be useful, but anal retentive corporations take a
dim view of downloading software.

 

[John Kelly]

It probably would be useful, but anal retentive corporations take a
dim view of downloading software.

You can't post the code and you can't download free software. What a
pity.

 

[gbostock]

You can't post the code and you can't download free software.  What a
pity.

You said it!

 

[Jim Gibson]

Narrow it down on what basis? Guessing?

Either educated guessing or just brute force: throw out a line; if the
problem remains, throw out another line and repeat. If the problem goes
away, put back that line and throw out another one. Repeat until only
lines that contribute to the problem remain. Then post those lines.

Educated guessing will allow you to throw out more than one line at a
time, but you are still guessing.

By the time you have completed this process, it is likely that you will
have diagnosed the problem and won't need anybody's help.

 

[Peter J. Holzer]

No prompt? Are you sure? Or is it possible that you just don't notice
the prompt because it is buried somewhere between the output from
myperl.pl?

"If there is any input" or "If you press return"? Please be specific.
The bash prints messages about stopped jobs only after you enter a
complete command (the zsh displays it immediately and then redisplays
the prompt and the partially entered command, if any).

Also, what is the exact message?

I.e. you still get output from myperl.pl on the screen? This is also
strange, because nohup normally redirects stdout and stderr to
"nohup.out".

(on some but not all systems, nohup also redirects stdin from
/dev/null).

If you don't get output you shouldn't write "the same thing happens",
but describe what happens.

A good way (if you are familiar with Unix system calls) to find out what
a program is doing is to use strace (Linux) or truss (Solaris) or tusc
(HP-UX) or whatever it is called on your system.

Nope, it reads from files, but the problem manifests before it gets to
the file read.


Narrow it down on what basis? Guessing?

Not quite. First comment out all the code which you think is never
called before the process is stopped (you say that it is stopped before
the first file is opened, so I guess this will get rid of the bulk of
the program. Verify that it is still stopped. Then comment out about
half of the remaining program, verify that the problem still exists. If
it doesn't, remove the comments and comment out the other half. Repeat
until you cannot remove any more without solving the problem. By then
the program is almost certainly small enough that you can see the cause
or that you can post it here.

- Hide quoted text -

Please remove these lines before posting. They contain no useful
information.

hp

 

[gbostock]

Thanks, your post led me to the solution to the problem and I didn't
have to guess at lines of code.

Sorry about the hide text business, it's an artifact of using Google.
I trimmed the whole thing this time

 

[Martijn Lievaart]

Thanks, your post led me to the solution to the problem and I didn't
have to guess at lines of code.

Care to share what was wrong? I'm interested now.

M4

 

[gbostock]

Care to share what was wrong? I'm interested now.

M4

When a command is issued from the perl program, you need to put an &
at the end of that command too. Backticks, qx and system all do a
clone and through dup wind up using the same I/O handles as where the
parent process came from. This puts a new command coming from the
parent process at the terminal, creating the situation as described by
Peter J. Holzer.

 

[Martijn Lievaart]

When a command is issued from the perl program, you need to put an & at
the end of that command too. Backticks, qx and system all do a clone and
through dup wind up using the same I/O handles as where the parent
process came from. This puts a new command coming from the parent
process at the terminal, creating the situation as described by Peter J.
Holzer.

Strange, because nohup should have redirected those handles. Besides,
when I issue another command from my perl code, whether to run it async
or not is an important property of my algorith. If I were to just put an
& at the back of the command line, my program will not do what it is
designed to do.

In fact, I often do that (execute other programs from a background
program) and it works as expected. So I still don't get it.

M4