Hi Jonathan
Thanks for the reply and bug reports.
I have tried your workaround but to no avail.
Our problem is that the restart of IDS does work correctly within a
script, even without the redirection (using 9.40.FC6 so your bug may be
specific to v10.UC3).
I have also tried the suggestion by Mladen to use the (undocumented)
method of starting the engine with oninit -d. This does not daemonize
the engine processes but runs in the foreground. However the databases
within the server are usable.
When I use oninit -d in the script, called from cron, the result is the
same ... Fast Recovery that does not recover!
Thanks again to both of you but no joy
Gerry
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
> 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