Re: Revived: Oninit from cron leaves engine in permanent fast
On 11/23/2005 10:23 PM, Jonathan Leffler wrote:
> 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
I think that "oninit -d" will not daemonize oninit processes
> 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
>
>
Best regards,
--
Mladen Jovanovski
Phone: +389 2 244 1140
Mobile: +389 75 400 309
COSMOFON - Mobile Telecommunications Services - A.D. Skopje
_______________________________________________________________
This e-mail (including any attachments) is confidential and may be protected by legal privilege. If you are not the intended recipient, you should not copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. COSMOFON A.D. Skopje shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system.
sending to informix-list