Bug 743597

I would say this is php bug (libedit?). It tries to do some terminal initialisation while in background. `php -f reproducer.php </dev/null' fixes the problem for me. Question is whether it makes sense to do something about where descriptors point to inside rlWatchdog.

(In reply to comment #2)
> I would say this is php bug (libedit?). It tries to do some terminal
> initialisation while in background. `php -f reproducer.php </dev/null' fixes
> the problem for me. Question is whether it makes sense to do something about
> where descriptors point to inside rlWatchdog.

Ah you are right, this behaviour happens also for not-segfaulting simple php script containing just one print statement.

(In reply to comment #3)

Not only that, you can have empty script and still still happens, actually it happens before any script is even opened and read.

(In reply to comment #2)
> I would say this is php bug (libedit?). It tries to do some terminal
> initialisation while in background. `php -f reproducer.php </dev/null' fixes
> the problem for me. Question is whether it makes sense to do something about
> where descriptors point to inside rlWatchdog.

Lets abstract from php. It seems any stdin causes it to stop - and somehow it makes sense, isn't it?

# rlWatchdog "echo tak to napis ; read napis ; echo diky diky" 60
:: [13:45:30] ::  Runnning echo tak to napis ; read napis ; echo diky diky, with 60 seconds timeout
Argh Blargh!: 2
[1] 27261
[2] 27262
tak to napis

[1]+  Stopped                 eval "$command; touch __INTERNAL_FINISHED"

 OR JUST:

[root@timothy 11948]# eval "echo tak to napis ; read napis ; echo diky diky" &
[1] 27454
tak to napis
[root@timothy 11948]# 

[1]+  Stopped                 eval "echo tak to napis ; read napis ; echo diky diky"

---

So I would say, in this state rlWatchdog does not work for any command requesting input from stdin. Not so good and not so bad, beakerlib user can (if know about it!) add dev null redirection by himself.

Assuming we are doing automated testing, interactive input should not be needed anyway anytime. So what about changing eval in rlWatchdog from:

eval "$command; touch __INTERNAL_FINISHED" &

to 

eval "$command; touch __INTERNAL_FINISHED" < /dev/null &

We cannot add redirection inside eval, since $command can be structured in any way. Does this makes sense?

(In reply to comment #5)

> Lets abstract from php. It seems any stdin causes it to stop - and somehow it
> makes sense, isn't it?
Better would be some option to php to not do anything with stdin.

> 
> So I would say, in this state rlWatchdog does not work for any command
> requesting input from stdin. Not so good and not so bad, beakerlib user can (if
> know about it!) add dev null redirection by himself.
User or "some" magic in beakerlib.

> 
> Assuming we are doing automated testing, interactive input should not be needed
> anyway anytime. So what about changing eval in rlWatchdog from:
> 
> eval "$command; touch __INTERNAL_FINISHED" &
> 
> to 
> 
> eval "$command; touch __INTERNAL_FINISHED" < /dev/null &
> 
> We cannot add redirection inside eval, since $command can be structured in any
> way. Does this makes sense?
I would not go redirection in this way. I'm not sure with this, but what about to close stdin? Redirect stdin? or...

In case of closing stdin, I would do tests with processes which do some magic with stdin - shells for example.

Some time ago, coreutils learned 'timeout' command. I'll make a research about whether it is present in supported older RHELs and port watchdog to it where possible (and deprecate it, because it really does not add any value now)

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

After re-reading, I would say this is not really a bug - the command under rlWatchdog simply did not end, and rlWatchdog noticed it and killed it. From my POV, everything works as expected...