SEO

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

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

Run oninit with an & after it.

oninit > myfile 2>&1 &

That will background it for sure!

Well if there is something then shouldn't IDS put a message in the
online.log to say it
has spotted this flag?

http://www.prstech.com/src/informix_faq/ifaq08.htm

"Environment variables to set before starting Online:-

AIOTRACE=1 Writes additional message to online.log"

and

"Another one is if you are using DR and want to see what's going on
between servers set DR_TRACE=1
and pipe oninit to a file."

And what do the CCFLAGS bits mean? Any plans to tell us?