APScheduler main loop throws exception IOError 514 about apscheduler HOT 16 CLOSED

Original comment by maoz_guttman (Bitbucket: maoz_guttman, GitHub: Unknown):

tnx.

from apscheduler.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

I decided to include this fix in 2.1.2. Thank you.

from apscheduler.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

Yes. I wish there was a way to reproduce the issue.
Is it possible for you to try running your software on a more recent Linux just to see if the problem occurs there too? I'd like to get to the bottom of this before I make a decision. I'm very reluctant to ignore exceptions if I don't understand when and why they are happening. I'm not rejecting your proposal, but I want to be clear about why it's needed.

from apscheduler.

Original comment by maoz_guttman (Bitbucket: maoz_guttman, GitHub: Unknown):

Yes. I did it in a naïve way.
I ran a Python program that just has: time.sleep(100).
Then I ran kill from Unix prompt on it with various signals (e.g. SIGTERM, etc.) but the "IOError 514 exception" did not happen.

Is that what you meant by interrupting the sleep with signals?

from apscheduler.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

But did you try interrupting the sleep with signals?

from apscheduler.

Original comment by maoz_guttman (Bitbucket: maoz_guttman, GitHub: Unknown):

Hi,

I was running time.sleep in a dummy script (using threads) for more than a week and have not yet hit the "IOError 514 exception".
I know that "IOError 514 exception" can happen since it happened again in the production tool/environment inside the APScheduler package.

I will be grateful if you will patch APScheduler as I described at the beginning of this thread.

Thanks,
Maoz

from apscheduler.

Original comment by maoz_guttman (Bitbucket: maoz_guttman, GitHub: Unknown):

Update: I am trying to reproduce it by calling time.sleep API but without success (yet)

from apscheduler.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

Good, because if this is only a bug in old Linux kernels, I don't want to add such a workaround.

from apscheduler.

Original comment by maoz_guttman (Bitbucket: maoz_guttman, GitHub: Unknown):

I will try next week to send a Unix signal during time.sleep() and will update you later.

from apscheduler.

Original comment by maoz_guttman (Bitbucket: maoz_guttman, GitHub: Unknown):

Didn't try since the try-except block "workaround" is good enough

from apscheduler.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

Yes but can you reproduce this problem by interrupting time.sleep() with a signal?

from apscheduler.

Original comment by maoz_guttman (Bitbucket: maoz_guttman, GitHub: Unknown):

In my Python script I am calling time.sleep API in few places and I had to wrap it in a try-except block since I hit that IOError 514 exception

from apscheduler.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

From what I found out, this seems to be a problem when the select() is interrupted by a signal. That might be a way to reproduce the issue more quickly.

from apscheduler.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

Wow, that is ancient. Can you verify that this is still a problem on present day kernels?

from apscheduler.

Original comment by maoz_guttman (Bitbucket: maoz_guttman, GitHub: Unknown):

#!tcsh
% uname --kernel-release
2.6.16.60-0.58.1.3835.0.PTF.638363-smp

from apscheduler.

Original comment by Alex Grönholm (Bitbucket: agronholm, GitHub: agronholm):

What Linux kernel version are you running?

from apscheduler.