G
George Potemkin
Guest
Thanks, Gus! Now all pieces of puzzle came together for me. > the startup code has checks to see if shared memory exists and if there are processes with old extant shared memory attachments before starting anything. if so, that code is supposed to prevent startup. In our case the shared memory was removed by broker after it got the fatal error (SYSTEM ERROR: unexpected wakeup from wait code -2, user 0). It's supposed that after the fatal errors the processes should leave a database without making any changes. I guess the broker has removed the shared memory segments and semaphores because it saw that watchdog is dead and nobody can care about the database anymore. As we know OS will not release the shared memory untill there are the processes that are connected to these segements. The startup code will be, of course, unable to see the previous memory. That is why I was afraid that db changes stored in old shared memory could be saved on disk after new multi-user session is started. It's a bit strange that only one of the old processes complained about the semaphores: [2018/02/23@17:07:08.502+0600] P-24554 T-1 I ABL 1971: (1075) Semaphore id 147 was removed [2018/02/23@17:07:08.502+0600] P-24554 T-1 F ABL : (6517) SYSTEM ERROR: Unexpected error return from semAdd -1
Continue reading...
Continue reading...