Re: Killing of sqlturbo (fwd)

Dave Kosenko Posted this last year. I found it to be a good practical discussion on the killing of Informix SQLTurbos. I re-post it now without his permission and beg his forgiveness. cheers j. } } } Naomi Walker writes: } |> Kill -14 typically safely takes out the runaway 4gl processes. When I get } |> desperate I try a round robin of kill -13, -14, -15, -1, -2. If a latch or } |> a lock is being held, i'd take Online to quiescent/offline and back } up again. (D.K.) } |> Its *much* better than restoring from archives. } } Of course, killing a front end process is different from killing an engine } (generally, it is safer). You BEST bet is, of course, to code signal } handling into your application. This means catching signals in your } esql/c programs and using the DEFER command in 4gl (or not using DEFER } and just using the interrupt to terminate it). In esql/c, catch your } signal, then issue a sqlint() followed by an sqlexit(), then exit the } application. } } } Now it's time for a bit of truth regarding engines and signals. The } following signals are IGNORED by sqlturbo (as of 5.0): } } SIGHUP } SIGINT } SIGQUIT } SIGTSTP } } You may send any of these signals to your heart's content; however, it } will do nothing to stop a sqlturbo. } } Three signals are caught: } } SIGTERM } SIGUSR1 } SIGPIPE } } Each of these cause a different action on the part of the sqlturbo. SIGUSR1 } is what is used by tbmode -z. However, tbmode also diddles with some shared } memory flags before sending this signal. If you send it yourself, it will } generally not have any effect since the appropriate shared memory flags } have not been set. Anyway, there is no advantage to sending SIGUSR1 yourself } over letting tbmode -z do it for you. } } To understand the remaining two, you need a basic understanding of how } sqlturbo works. Basically, once it gets started up, it will sit in an } infinite loop reading messages from the pipe (from the client process) } and taking actions based on that message. When the action is complete, } and you come back to the top of the loop, a return message will have been } placed on the pipe (which the client reads and processes). Normally, } this loop will only be terminated when you exit your client application } (or use sqlexit(), which has the same effect). } } A SIGPIPE is generated whenever a process attempts to write to a pipe that } has no reader. We catch SIGPIPE and set a flag. At the top of the loop } mentioned above, this flag is checked. So, if the client goes away (so } there is no reader on that end of the pipe), when sqlturbo tries to write } its return message to the pipe, a SIGPIPE is generated, we set the flag } and continue. Since the very next action after writing anything to the } pipe is to return to the main loop, the flag is checked and the loop is } exited. sqlexit() accomplishes this by simply closing the client end of } the pipe. } } Generally, whenever a client goes away, the engine should follow } suit. If it is blocked on a read from the pipe (waiting for the next } request) it will get an EOF and terminate. If it attempts to write a return } message to the pipe, it will get a SIGPIPE. When the engine is busy doing } work when the client goes away, though, the situation changes. Until it } attempts a write on the pipe, or tries to read from the pipe, it will not know } that the client has gone. Eventually, it will get around to its write and } terminate, but that could take a while if it is doing something that takes } a lot of time. } } Finally, we have our SIGTERM. This signal is caught and another global flag } is set. This flag is checked all over the place in the sqlturbo code, and } control is passed back to the main loop (with a message indicating that the } statement was interrupted passed back: -213); the engine goes back to blocking } on the read from the pipe. Now the flag is not checked after every statement; } more like after every "unit of work" where the definition depends on the } type of activity. So it may not have an immediate effect, but it will have } an effect pretty quickly. If the client has gone away, the write of the -213 } to the pipe will generate a SIGPIPE and the loop will be terminated, or the } read will get EOF and the loop will be terminated. } } So, if tbmode -z does not work, and you cannot shut your system down (really } the best alternative), the next best thing to do is send a SIGTERM to the } sqlturbo (causing it to interrupt its current work) followed by a SIGPIPE } (if the SIGTERM alone doesn't do it). If this combination has no effect } after a reasonable amount of time, you really should do a shutdown. Any } other signal sending is likely to bring the system down anyway (abort mode). } } Dave } } The Killing of Sqlturbo } } "The last time I saw sqlturbo alive } Was in the summer of '75 } It said it was in a critical section } I said 'I'm pleased'... } } (apologies to Rod Stewart) } Disclaimer: These opinions are not those of Informix Software, Inc. } ************************************************************************** } "I look back with some satisfaction on what an idiot I was when I was 25, } but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney } -- _____________________________________________________________________________ Jack Parker - Hewlett Packard, DMD/IS Boise, Idaho, USA jparker@hpbs3645.boi.hp.com _____________________________________________________________________________ What's the difference between a duck? _____________________________________________________________________________ Any opinions expressed herein are my own and not those of my employers. _____________________________________________________________________________