Re: Revived: Oninit from cron leaves engine in permanent fast

On 29 Nov 2005 10:42:01 -0800, david@smooth1.co.uk <david@smooth1.co.uk> wrote: > Run oninit with an & after it. > > oninit > myfile 2>&1 & > > That will background it for sure! You omitted the '-d', which is part of the answer. There are occasions when R&D or Tech Support would find the '-d' option useful but very few occasions when a regular customer would use it - especially not in production. You should also redirect standard input - probably to /dev/null: (oninit </dev/null >/dev/null 2>&1) & I use the parentheses to run a sub-shell in the background, and that is responsible for running oninit. If you want to, you can include a second & on its own inside the parentheses after the 1, but it is hardly necessary. The i/o redirection there means that none of the standard I/O streams (stdin, stdout, stderr) is connected to the terminal or pipe, so you should be OK unless you have some weird piece of code somewhere that plays silly buggers with i/o redirection - like doing: exec 1>&3 If that came before the command above, that would keep the original stdout open despite the i/o redirection I showed. If this doesn't solve the problem, then we may have to resort to some tricky stuff. If you have the lsof (list of open files) program, maybe you should run that in the cron-run script to a file and establish which files are open. Failing that, I have a poor man's version of 'lsof'; the current incarnation just lists output like 'ooo---o----o--' to show that file descriptors 0, 1, 2, 6, and 11 (if I counted correctly) are open and the others are closed. You'd expect that to produce 'ooo-----------' for a cron-run job; if there are any other files open, they could be a source of trouble. A fairly easy enhancement to the program would be to print the device information (file inode number and device major/minor) for each open file; that approaches 'lsof' more closely. Gerry Cassidy wrote: >When I use oninit -d in the script, called from cron, the result is the >same ... Fast Recovery that does not recover! Have you really, really tracked all the environment - including things like current directory and umask and whatnot - in the script run by cron? Have you done a line-by-line comparison of the environment for the cron-run script with your command-line environment? Have you tried using 'env -i' and setting explicitly the Informix environment variables that are truly necessary in your machine? I set just 7 of them: INFORMIXDIR, INFORMIXSERVER, ONCONFIG, HOME, PATH, SHELL, TZ. IDS runs nicely for me - and did when run from a cron script too. -- 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