Re: oninit: Dictionary Cache and SPL Routine Cache error

Hi Jef. Just a thought. I think truss -f -o file oninit -v is your help. -f option means -f Follows all children created by fork() or vfork() and includes their signals, faults, and system calls in the trace output. Normally, only the first-level com- mand or process is traced. When -f is specified, the process-id is included with each line of trace output to indicate which process executed the system call or received the signal. Just my $0.02. -- Tsutomu Ogiwara from Tokyo Japan. >From: "Jef" <jeferymiller@yahoo.com> >Reply-To: "Jef" <jeferymiller@yahoo.com> >To: informix-list@iiug.org >Subject: Re: oninit: Dictionary Cache and SPL Routine Cache error >Date: 3 Oct 2005 21:34:31 -0700 > >Looks like it is forking at the end and dying. >------- >open64("/dbms/informix/etc/.infos.demo_on", O_RDWR) = 0 >fcntl(0, F_SETLK64, 0xFFBD6D70) = 0 >read(0, "\\007\\0\\0\\00201\\b\\0\\0\\0\\0".., 264) = 264 >read(0, "\\001\\0\\0\\0\\0\\0\\0 R V H01".., 264) = 264 >read(0, "\\004\\0\\0 / d b m s / i n".., 264) = 264 >read(0, "\\005\\0\\0 f i n a n c e -".., 264) = 264 >read(0, "\\006\\0\\0 I B M I n f o".., 264) = 264 >read(0, 0xFFBD6E60, 264) = 0 >llseek(0, 0, SEEK_END) = 1320 >write(0, "\\0\\b\\0\\0 / d b m s / i n".., 264) = 264 >fcntl(0, F_SETLK64, 0xFFBD6D70) = 0 >close(0) = 0 >umask(022) = 07 >umask(07) = 022 >getpid() = 4130 [4129] >sigprocmask(SIG_SETMASK, 0xFF3AA074, 0xFFBD7250) = 0 >fork() = 4131 >sigprocmask(SIG_SETMASK, 0xFFBD7250, 0x00000000) = 0 >lwp_schedctl(SC_STATE|SC_PREEMPT, 0, 0xFFBD7124) = 0 >sigaction(SIGTERM, 0xFFBD6FF8, 0xFFBD71C0) = 0 >wait() = 4131 [0x0100] >_exit(1) >-------------- > >I can send the full dump logs if you think that would be useful. The >only *.iem file it is opening is olserver.iem and that one is there. > >I'm wondering if the missing message file isn't just a red herring and >the real errors lie somewhere else. sending to informix-list

Yes, thanks, that worked. Ok, the file it is looking for is os.iem. And, it is only found in the 4gl Runtime, 4gl Dev, and Client SDK. I extracted the os.iem file from each tar and they are all identical. The permissions are correct, 644. So, it is finding the file, but not finding the error. This may lead lead back to the installation order. I will analyze the output and post more later.

I did the following: # truss -fr all -o oninit.log /dbms/informix/bin/oninit -ivy The results showed that there were some errors in the sub processes that were not killing the main process. One place says, in essence: Physical Recovery failed Logical Recovery failed Cannot open Chunk %s Cannot open DBspace Performance Improvement Possible Database failure: %s Data Replication failure Archive completed %s Now, that might just be enumerating a list of bad things that could happen, I'm not sure. There's more: Archive aborted Log Backup complete Log Backup aborted Logical Logs are full -- backup Dynamic Server resource overflow Long Transaction detected %s: cannot allocate memory ... Log file required No space for log file Then, it begins the initializing of ASF as if everything were Ok. --Jef

Jef wrote: > I did the following: > # truss -fr all -o oninit.log /dbms/informix/bin/oninit -ivy > > The results showed that there were some errors in the sub processes > that were not killing the main process. > > One place says, in essence: > Physical Recovery failed > Logical Recovery failed > Cannot open Chunk %s > Cannot open DBspace > Performance Improvement Possible > Database failure: %s > Data Replication failure > Archive completed %s > > Now, that might just be enumerating a list of bad things that could > happen, I'm not sure. IDS loads up quite a lot of messages at startup - just in case they might be needed. I think that's what's happening here. Alarming as some of them look, there's nothing actually amiss. Indeed, you can spot the difference - these were, I'm sure, messages that were read into memory; it is the written messages that you have to worry about. > There's more: > Archive aborted > Log Backup complete > Log Backup aborted > Logical Logs are full -- backup > Dynamic Server resource overflow > Long Transaction detected > %s: cannot allocate memory > ... > Log file required > No space for log file > > Then, it begins the initializing of ASF as if everything were Ok. But something, somewhere, is failing and causing everything to terminate... -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/