in reply to Re^3: mod_perl, prefork mpm and alarms
in thread mod_perl, prefork mpm and alarms

To quote from my original post,

What's happening is that the Apache process is dying about the time that the alarm is set. Dying is bad, in this context. OK, in any context.

Running this code from the command line works fine, this I'm trying to understand why setting an alarm (my guess, based on output from strace) might be causing the problem. After commenting out all of the calls to alarm, I'm still seeing problems: 

getgroups32(0x20, 0xbfffe2f0)           = 1
stat64("/opt/fonts-ecs-2004-07-23/mscorefonts", {st_mode=S_IFDIR|0755,
+ st_size=4096, ...}) = 0
getgroups32(0x20, 0xbfffe2f0)           = 1
rt_sigaction(SIGALRM, {0x4044fc80, [], SA_RESTORER, 0x402b88f8}, {SIG_
+DFL}, 8) = 0
pipe([9, 10])                           = 0
ioctl(9, SNDCTL_TMR_TIMEBASE, 0xbfffe1b0) = -1 EINVAL (Invalid argumen
+t)
_llseek(9, 0, 0xbfffe200, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
ioctl(10, SNDCTL_TMR_TIMEBASE, 0xbfffe1b0) = -1 EINVAL (Invalid argume
+nt)
_llseek(10, 0, 0xbfffe200, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
fcntl64(9, F_SETFD, FD_CLOEXEC)         = 0
fcntl64(10, F_SETFD, FD_CLOEXEC)        = 0
pipe([11, 12])                          = 0
ioctl(11, SNDCTL_TMR_TIMEBASE, 0xbfffe1b0) = -1 EINVAL (Invalid argume
+nt)
_llseek(11, 0, 0xbfffe200, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
ioctl(12, SNDCTL_TMR_TIMEBASE, 0xbfffe1b0) = -1 EINVAL (Invalid argume
+nt)
_llseek(12, 0, 0xbfffe200, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
fcntl64(11, F_SETFD, FD_CLOEXEC)        = 0
fcntl64(12, F_SETFD, FD_CLOEXEC)        = 0

[download]

Something still appears to be setting an alarm

rt_sigaction(SIGALRM, {0x4044fc80, [], SA_RESTORER, 0x402b88f8}, {SIG_DFL}, 8) = 0

that I presume is breaking Apache, even though I believe I'm running under the prefork MPM.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Replies are listed 'Best First'.
Re^5: mod_perl, prefork mpm and alarms
by perrin (Chancellor) on Nov 29, 2006 at 20:26 UTC
    Something other than your script is setting an alarm? Maybe you should show us the code you use to call ghostscript. The above trace looks more like a problem with pipes to me.
[reply]

      I owe you a beer. You're absolutely right .. the code that I'm calling does do some futzing around with pipes to call Ghostscript .. it's not my code, I'm just calling it, but I should have guessed (or even checked) that there were pipes involved.

      And that's not on .. Apache has taken control of the input and output pipes in the main process .. meaning if I want to do something *like* that, I have to start a sub-process and talk to it directly. So Apache was burping when it saw the code I was calling start to rearrange the plumbing, I guess.

      Well, it's going to get tricky later when I want to start a sub-process if one isn't yet running for a document, use it for a page image, and then leave it in place for subsequent requests for the same document.

      But Momma, that's where the fun is! --Manfred Mann

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

[reply]
        STDIN and STDOUT are tied under mod_perl, but you should be able to open pipes to another process. Usually, the best way to handle this kind of thing is a separate job queue process, as suggested by some others.
[reply]

In Section Seekers of Perl Wisdom