Revived: Oninit from cron leaves engine in permanent fast

Reviving some ancient history... On 21 Oct 2005 02:54:25 -0700, gerry.cassidy@dsl.pipex.com < gerry.cassidy@dsl.pipex.com> wrote: > > Thanks TBP, I think you may have hit on something there. The > difference between ps outputs taken from the cron startup and the > manual startup is shown below; > > < informix 585744 770152 0 02:54:26 - 0:00 oninit -v > < informix 643312 585744 76 02:54:27 - 84:26 oninit -v > < informix 680146 803060 0 02:54:30 - 0:00 oninit -v > [...] > < informix 811086 803060 0 02:54:33 - 0:00 oninit -v > < informix 827566 803060 0 02:54:28 - 0:00 oninit -v > --- > > informix 643318 1 0 04:20:49 - 0:03 oninit -v > > informix 680148 803066 0 04:20:55 - 0:00 oninit -v > > informix 684192 803066 0 04:20:51 - 0:00 oninit -v > > [...] > > informix 790634 803066 0 04:20:50 - 0:00 oninit -v > > informix 803066 643318 0 04:20:50 - 0:00 oninit -v > > informix 827568 803066 0 04:20:53 - 0:00 oninit -v > > informix 831622 803066 0 04:20:56 - 0:00 oninit -v > > I agree that the main oninit should have a PID of 1 [...] > I've finally found a bit of time to do some experimenting - using IDS 10.00.UC3 on Solaris 8. I've entered 2 bugs and a feature request: B175152: IDS does not properly daemonize itself B175153: "onstat -r 60 -" should include a date/time in its output (feature request) B175154: "onstat -r 60 -" should terminate once it detects IDS has terminated The first bug shows up if you restart IDS in a shell script such as: ( . 10.00.UC3 # Set IDS environment onmode -ky oninit ) | mailx -s "some subject" whoever@wherever.com The mailx command doesn't terminate, because there are child processes of the oninit process that still have the pipe open for writing. IDS should detach itself from its standard input, standard output and standard error. Consideration of 'oninit -v' indicates this should happen after the verbose mode is complete. The workaround is to run oninit with i/o redirection: oninit </dev/null >/dev/null 2>&1 This permits the script to stop the server, and restart it - downside, you don't see any diagnostics from oninit unless you poke around the online log file. With the workaround in place, I can bounce my server up and down via cron quite happily - I've been doing it every ten minutes for a hour or two now, No getting stuck in fast recovery. That means I've not been able to reproduce your problem. The other bug and the feature request are self-explanatory and semi-trivial - minor usability nitpicks rather than anything outrageously awful. Does this help anyone? Dunno; the fact that the parent process is not terminating and leaving the system daemonized is weird. I'm wondering if there's a setting - possibly in ONCONFIG, or possibly in the environment, or possibly in the command line options (undocumented ones) - that tells IDS not to daemonize itself. This sort of thing tends to be useful in R&D debugging, and I wonder if something like a bit was set in CCFLAGS in ONCONFIG under direction from Tech Support and was not unset afterwards, and this is causing the misbehaviour. Exactly how are you restarting your server? -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/ sending to informix-list