: We opened /dev/null to protect FD #1, but descriptor #1 is already occupied

Hi

since we migrated from 3.8.8 to 3.8.11, I see the following warning in
the logs:

[warning]: We opened /dev/null to protect FD #1, but descriptor #1 is
already occupied at /opt/rt3/bin/webmux.pl line 79

It appeared 175 times since last Sunday.

It comes from

 if ( !$protect_fd && $ENV{'MOD_PERL'} && exists 

$ENV{‘MOD_PERL_API_VERSION’}
&& $ENV{‘MOD_PERL_API_VERSION’} >= 2 && fileno(STDOUT) != 1
) {
# under mod_perl2, STDOUT gets closed and re-opened, however
new STDOUT
# is not on FD #1. In this case next IO operation will occupy
this FD
# and make all system() and open “|-” dangerouse, for example DBI
# can get this FD for DB connection and system() call will close
# by putting grabage into the socket
open( $protect_fd, ‘>’, ‘/dev/null’ )
or die “Couldn’t open /dev/null: $!”;
unless ( fileno($protect_fd) == 1 ) {
warn “We opened /dev/null to protect FD #1, but descriptor
#1 is already occupied”;
}
}

Should I worry about it ?
Can I do something to avoid getting this warning ?

Gerard

Hi

since we migrated from 3.8.8 to 3.8.11, I see the following warning in the
logs:

[warning]: We opened /dev/null to protect FD #1, but descriptor #1 is
already occupied at /opt/rt3/bin/webmux.pl line 79

It appeared 175 times since last Sunday.

[snip]

Should I worry about it ?

Yes, you should. You can experience hardly explainable problems
because of this situation. Effect depends on what gets FD #1. If it’s
database then in some situations RT can loose connection to the DB
right in the middle of processing user’s request.

Can I do something to avoid getting this warning ?

One of the following:

  1. upgrade mod_perl to 2.0.5
  2. use “SetHandler modperl” instead of “SetHandler perl-script”. This
    change may require additional options. See the following link for
    differences and how to compensate them with additional options:
  1. Use FCGI

Gerard

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Boston March 5 & 6, 2012

Best regards, Ruslan.