Hello There, > My script is a socket client talking to a mainframe-based server. There is > database processing involved on the mainframe side and MQ involved on the > client side.
MQ ? Message Queuing ? > I want my script to be in a continuous loop with a 30 second pause. While > it is 'working' I want to delay kill signal from a user (root in this > case) until it has reached a 'safe' point. This is not very different > from the 'transaction logic' we encounter in database processing. If the > script is killed mid-flight, it would be time-consuming to investigate and > re-start. > > How does one program for such a situation? Well, you can make the script (are we talking the client here?) safe during those 30 seconds by blocking (not ignoring) signals during your work window (30 seconds might be a wee too much, if I were to kill-SIGTERM a program and it did not obey in a second or two more serious action would be taken as in kill-SIGKILL). This way you can be safe from all signals that default to termination but can be handled, as you just clean up and exit in your signal handler and handle the signal only when you are "safe" to do so. However, SIGKILL and SIGSTOP you just can't avoid. As I was saying, it is a fact of life, if *NIX shouts "DIE" or "HALT" in those terms, your process will obey, no exceptions. You can consider your program being killed mid-flight in those terms a rare occurrance if you are responsive in handling nicer messages like SIGTERM, but it can happen and you should add a way to detect that kind of death if you want to insure trouble-free operation. Think about it this way: it might be time consuming to recover/restart, but as it will hopefully essentially almost never happen, you might just need to detect that it happened and restart simply re-doing the work. This of course depends on the details of your program's work.... I must caution however, if the user does not see a response from SIGTERM it is likely to fire with the big ammo and use SIGKILL, so I would choose a much smaller granularity than 30 seconds. -F _______________________________________________ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
