Can anyone say whether this problem is limited to Linux, or does it exhibit itself on other server platforms? Thanks.
At 09:34 AM 12/3/2012, Andrew Raibeck wrote: >Hi Zoltan, > >Looks like we have one or two other customers reporting this. My >recommendation would be for you to open a PMR. Optionally, if you want to >be as pro-active as possible, perform the following steps in advance (this >is the current set of doc being requested for this issue): > >1. Stop TSM, kill if necessary. > >2. Start dsmserv in the foreground. > >3. Wait for TSM to come completely up. > >4. In the TSM server console, enable tracing by issuing: > > trace enable ADM DB THREAD TM ADDMSG > trace begin /tmp/tsmhalttrace.out > >(for the "trace begin" command, specify whatever directory and trace file >name if you want) > >5. Issue the HALT command on the TSM server console > >6. Wait 10 minutes. > >7. Open a root terminal on the system where TSM is running and issue the >following commands (and save the output): > > ps -ef | grep dsmserv > ps -ef | grep db2 > >8. Locate the process ID (PID) for dsmserv AND db2sysc from the ps output. > >9. Issue the pstack command against the dsmserv PID and save the output, >e.g.: > > $ procstack 1234 > >10. Issue the pstack command against the db2sysc PID and save the output, >e.g.: > > $ procstack 1235 > >10. Wait 10 minutes. > >11. Repeat steps 7, 8, 9, and 10. Save the output. > >13. Repeat steps 7, 8, 9, and 10 again, saving the output. > >14. Copy and save all of the on-screen output from the TSM console. > >15. Restart TSM. > >16. Login as instance owner, issue "db2support -d tsmdb1 -c -g -s", save >the db2support.zip generated > >Once you have the PMR created, you can send in the doc that you collected: > >1.The TSM server console output > >2. The TSM server trace file > >3. The three iterations of the "ps" output > >4. The three iterations of pstack output against dsmserv > >5. The three iterations of pstack output against db2sysc > >6. The db2support.zip file > >Best regards, > >Andy Raibeck >IBM Software Group >Tivoli Storage Manager Client Product Development >Level 3 Team Lead >Internal Notes e-mail: Andrew Raibeck/Hartford/IBM@IBMUS >Internet e-mail: stor...@us.ibm.com > >IBM Tivoli Storage Manager support web page: >http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager > >"ADSM: Dist Stor Manager" <ADSM-L@vm.marist.edu> wrote on 2012-12-03 >08:45:17: > >> From: Zoltan Forray <zfor...@vcu.edu> >> To: ADSM-L@vm.marist.edu, >> Date: 2012-12-03 08:55 >> Subject: Re: 6.3.3.000 server wont HALT >> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@vm.marist.edu> >> >> This is now becoming a consistent / persistent problem. I had to kill -9 >> to stop the dsmserv process. I restarted the server (via service .. >> start) and there didn't seem to be any damage done. >> >> However, attempting to stop/halt it, again, produced the same result - >> dsmserv using 200% CPU and after 2-hours I had to kill -9. >> >> So, obviously there are big enough changes in 6.3.3 vs 6.3.2, to cause >> problems like this, since none of my 6.3.x or 6.2.x servers exhibit >> this behavior. >> >> Any suggestions on how to diagnose this "issue" before I contact IBM and >> open a PMR? >> >> >> On Thu, Nov 29, 2012 at 2:04 PM, Zoltan Forray <zfor...@vcu.edu> wrote: >> >> > Just did my first install/conversion of a 6.2.3 TEST server to >6.3.3.000 >> > (RH Linux) >> > >> > While the install and startup went fine, it won't HALT. >> > >> > After the install/upgrade, I got in via dsmadmc just fine. Checked the >> > actlog - saw all the schema changes/upgrades. Updated/registered the >> > licenses and then issued HALT. Got the usually warning and said YES. >> > >> > Now it has been sitting for >25-minutes since the halt. >> > >> > Can't get back in via dsmadmc. >> > >> > Top shows dsmserv using >200% CPU. >> > >> > I tried standard kills, with no luck. I hate to do a kill -9 but will >if >> > I don't have a choice. >> > >> > What the heck is it doing? Should I wait longer or just kill it with >> > extreme prejudice? >> > >> > -- >> > *Zoltan Forray* >> > TSM Software & Hardware Administrator >> > Virginia Commonwealth University >> > UCC/Office of Technology Services >> > zfor...@vcu.edu - 804-828-4807 >> > Don't be a phishing victim - VCU and other reputable organizations will >> > never use email to request that you reply with your password, social >> > security number or confidential personal information. For more details >> > visit http://infosecurity.vcu.edu/phishing.html >> > >> > >> >> >> -- >> *Zoltan Forray* >> TSM Software & Hardware Administrator >> Virginia Commonwealth University >> UCC/Office of Technology Services >> zfor...@vcu.edu - 804-828-4807 >> Don't be a phishing victim - VCU and other reputable organizations will >> never use email to request that you reply with your password, social >> security number or confidential personal information. For more details >> visit http://infosecurity.vcu.edu/phishing.html >> -- Paul Zarnowski Ph: 607-255-4757 CIT Infrastructure / Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: p...@cornell.edu
