Hmmm...I just realized... Had the same type of issue with UV 9.6 on AIX 5.2 so we had a similar kill process, often telnet connections would not release especially if the user had shelled out to perform a process (most notably to go to SMIT), along with samba sessions...the spooler would also be stopped.
Then uv.rc would be executed to restart universe, and the spooler restarted If the shutdown was performed out-of-sync it would at times result in a memory segment error and the shutdown and system up process would have to be executed over. (this was fun cross-eyed at 3AM) If you aren't doing so already, I would suggest capturing all cron errors to a log file you can easily review -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hona, David S Sent: Thursday, May 11, 2006 5:15 AM To: [email protected] Subject: RE: [U2] [UV] unirpc daemon, stopping and re-starting it from cron We've had similar issues and found that it isn't a UniVerse issue. It was processes using UniRPC connections (InterCall, UniObjects, UniCall/OBDC, etc.) still being active during the shutdown. These processes keep their socket connections open. This can prevent UniRPC from starting back up. The problem sounds like that you may have a process(es) using UniRPC when you shutdown UniVerse. If this is the case, under Sun Solaris and UV 9.1.4 we would see processes still using UniRPC go into "FIN_WAIT_2" state for their still open TCP socket connection. If that was the case, we could guarantee that the UVRPC daemon (has it was called before UV 9.5.x) wouldn't start back up. Once those TCP connections cleared (went "away"), it was okay to start back up...sometimes it took awhile to clear though. Check what connections you have active, by issusing a: $ netstat -a | grep uvrpc *.uvrpc *.* 0 0 49152 0 LISTEN If nothing is connected, you're safe to shutdown (like the above example). If you got processed connect - it may be bad. Strangely, under UV 10.1.12 and Solaris 9, we can now happily stop UV and start it up again...UniRPC *seems* to come backup -- even if processes are connected with open sockets. Could be wrong or just plain lucky, of course. We deal with this situation by adding to the uv.rc script, our own "uv_kill_processes" script which looks for UV processes and the shared memory segments. It loops until all are UV processes are killed (up to 4 attempts). This also deals with the UV shutdown process "aborting" if shared memory segments aren't released. Hopefully, this should help you out in some way. Regards, David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacques G. Sent: Wednesday, May 10, 2006 6:02 AM To: [email protected] Subject: [U2] [UV] unirpc daemon, stopping and re-starting it from cron Hello, We have a cron job which does the following: 1- Uses Universe's uv.rc script to stop Universe and unirpc daemon 2- Make a backup of the Production account into a different filesystem on the production machine. 3- Restart Universe & unirps using the uv.rc script 4- Start the backup to tape of the copy of the production environment. When Universe is re-started along with the unirpc daemon within the cron job, Universe works but the unirpc daemon doesn't work correctly. It must be stopped manually from the uv menu and re-started. Has anyone here encountered a similar problem ? I've tried to get support help from IBM but I get the run-around. I'm told that IBM won't debug my companies script even though I've repeatedly told them that the script we are using the uv.rc script that was written by IBM. We are running Universe 10.1.8 on a HP.UX 11i machine. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
