Anonymous | Login | Signup for a new account | 12-17-2024 08:32 PST |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0000400 | [Resin] | minor | always | 09-25-05 00:00 | 01-17-06 10:45 | ||||
Reporter | user402 | View Status | public | ||||||
Assigned To | |||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.0.14 | ||||||
Summary | 0000400: wrapper.pl stderr going into limbo | ||||||||
Description |
RSN-446 The resin wrapper.pl script has a small bug in it: It closes STDOUT and STDERR and reopens them to the chosen jvm-log file, but it actually reopens STDIN and STDOUT leaving STDERR in limbo. The effect is that the JVM's STDERR (where System.err goes) gets redirected somewhere useless. You can check this by entering the following command: ls -l /proc/nnnn/fd where "nnnn" is the process-id number of one of the resin java processes (threads) and observing that file descriptors 0 and 1 (STDIN and STDOUT) both point to jvm.log and file descriptor 2 (STDERR) points to some weird place. Correcting this bug *may* result in a few more diagnostics ending up in the log files! Here is a diff (from Adrian Pronk) with changes: *** wrapper.pl.in Wed May 18 06:18:25 2005 --- wrapper.pl Sun Sep 4 14:44:06 2005 *************** *** 714,721 **** --- 714,724 ---- close(STDOUT); close(STDERR); + my $haveStdin = defined(fileno(STDIN)); + open(STDIN, "</dev/null") unless $haveStdin; open(STDOUT, ">>$jvm_log"); open(STDERR, ">&STDOUT"); + close STDIN unless $haveStdin; exec("$JAVA_EXE $JAVA_ARGS $class -socketwait $port $conf $RESIN_ARGS"); print(STDERR "Can't start java: $JAVA_EXE $JAVA_ARGS $class $conf $RESIN_ARGS"); |
||||||||
Additional Information | Debian Sarge | ||||||||
Attached Files | |||||||||
|
There are no notes attached to this issue. |
Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
31 total queries executed. 25 unique queries executed. |