in reply to trace / debug rogue signal

mhearse:

While I'm not aware of any way to see which process send you a signal, I am wondering if you might possibly be hitting a ulimit problem? Perhaps your program is running overlong and the kernel thinks it's been long enough or some such?

...roboticus

Replies are listed 'Best First'.
Re^2: trace / debug rogue signal
by mhearse (Chaplain) on Jul 25, 2007 at 23:14 UTC
    Hmmm... That is possible. I should also mention that this only happens when running from the web. Running the same thing from the command line doesn't receive a SIGKILL.
[reply]

      In that case, I'd definitely do a ulimit -a to report the limits for both your account and the one running the web server. Then I think I'd have a look at the environment variables ... just for good measure.

      ...roboticus

[reply]
[d/l]
Re^2: trace / debug rogue signal
by mhearse (Chaplain) on Jul 26, 2007 at 04:07 UTC
    I checked the ulimit for a regular user and the webserver user. They both appear to be unlimited.
[reply]

      mhearse:

      I have no Apache-fu, but perhaps it manages its child threads and kills 'em when it considers them unresponsive?

      The only other suggestion I can think of is to perhaps suspend all other processes that aren't absolutely critical for your application and see if the signals go away. Then you can use a binary search to figure out which one of the ones you turned off was the culprit.

      ...roboticus

[reply]
Re^2: trace / debug rogue signal
by mhearse (Chaplain) on Jul 26, 2007 at 22:24 UTC
    It was a ulimit after all. Not one enforced by the operating system, but someething tied into our proprietary system...
[reply]

      mhearse:

      I'm glad you found it!

      I'm, however, slightly disappointed that we didn't get to see an answer to your original question. It would be interesting to have a way to identify the sender of a signal....

      ...roboticus

[reply]

In Section Seekers of Perl Wisdom