R
Rohan
Guest
As expected, plain old ‘kill PID’ did not work on the _progres process. As it was now overnight / non-busy hours for us, we chose not to try 'kill -9 PID' on the _progres process to end the transaction, and instead got "most" users to log out. Then shutdown the db with 'Unconditional Shutdown'. The shutdown took a few minutes longer than normal. The process disappeared with the shutdown. The server was not shutdown, although it may have been better for a proper clean up. I won’t post the full db.lg entries unless someone is interested, but we received various Progress ‘error’ codes and messages in the db log file: (-----) Sending signal 12 to user 269 (-----) Sending signal 14 to user 269 (-----) Sending signal 15 to user 269 (15194) Database activity did not finish before… (2251) Destroyed user 269 pid 29319 (334) Multi-user session end. (16869) Removed shared memory with segment_id: 425997 Next truncated the BI file. Ran bigrow Started db with no obvious problems. On the subject of a list to do when (or before) this happens... To produce a core file and protrace, a pre-requisite is to set "core file size" to a non-zero value, for the db owner. The Linux ulimit -c command can be used to set the core file size to unlimited or some value in kilobytes. Size of 0 will not allow core files etc to be created. This was the case for us. These KB's were useful: Guidelines on the use of UNIX kill command to stop a process (This suggests an order of kill commands https://knowledgebase.progress.com/articles/Article/P14679 How to produce a stack trace for a running OpenEdge process without killing it http://knowledgebase.progress.com/articles/Article/P112486 How to produce a readable stack trace using PROSTACK? http://knowledgebase.progress.com/articles/Article/P2262 Anyway, we may have got away with it this time. Thanks all for assistance.
Continue reading...
Continue reading...