Would you be able to remotely detach a screen session and reattach it for debugging?
Assuming you don't know the user's password and sudo is available. At your terminal, 1. Find screen socket for user blahblah. sudo -u blahblah screen -ls 2. Detach the screen session sudo -u blahblah screen -d socket 3. Attach that detached session sudo -u blahblah screen -r socket You have to use your keyboard to debug UniData program anyway... so just take over a screen session from a user. :) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, August 10, 2010 11:50 AM To: [email protected] Subject: [U2] Sending interrupt to UniBasic program All, I'm hoping the bit-heads in the group can help me out with this one. It's kind of difficult to explain, but I'll try my best. My apologies for any lack of clarity. What we're trying to do is automate a third-party batch process. The automation piece is working well. But there's one requirement that's proving problematic, with two key requirements at play. First, batch process must run automagically and completely unattended. Second, operators must have the option to interact directly with the automated batch for trouble-shooting purposes. The second requirement is what's presenting the challenge. Since we need to be able to directly interact with the batch process, we can't use a phantom, since any keyboard I/O causes a phantom to terminate. The solution we chose was to run everything under GNU Screen. If you aren't familiar with Screen, here's a one sentence description from our friends at GNU -- "Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells." You can check http://www.gnu.org/software/screen for more info. I think of Screen as a terminal emulator that runs locally on the server. So if you start screen and then launch UniData from within your screen session, you are safe if the connection from your workstation is dropped; everything continues to run on the server. You just need to issue a command to reconnect to your screen session and you're back in business. Very handy tool. If the batch runs with no issues, this works well. But if we need to diagnose a run-time issue, e.g. a process appears to be hung, we need to do things like send ctrl-c to break the current program. This is where the problem comes in. Screen seems to be sending ctrl-c (or any other interrupt, for that matter) to udt, not the program that is running under udt. This causes the udt session to end which kills the batch process when all we want to do is get to the debug prompt. Questions to the Screen users group have not generated helpful answers. Here's an attempt at an illustration of what I'm talking about. Nesting indicates that a process is running under the outer process. Non-Automated: Can press ctrl-c while PROG1 is running to get to debug prompt AIX udt PROG1 Automated: Ctrl-c and AIX kill's are directed to udt, not PROG1 AIX screen udt PROG1 Does anyone have any thoughts on how to resolve this? My hope is that there's a way to send an interrupt from outside that will be directed towards a specific program. Environment info: AIX 5.3 UniData 7.1 TIA, Brad U.S. BANCORP made the following annotations --------------------------------------------------------------------- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. --------------------------------------------------------------------- _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
