Doesn't it figure. Now that I ran the server interactively to setup the trace, it is halting just fine.
Don't know what to think, now. On Mon, Dec 3, 2012 at 10:28 AM, Zoltan Forray <zfor...@vcu.edu> wrote: > Thanks Andy. Glad to know I am not the only one. Will collect the info > and open a PMR. Just another reason they call it the "bleeding edge" ;--) > > > On Mon, Dec 3, 2012 at 9:34 AM, Andrew Raibeck <stor...@us.ibm.com> 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 >> > >> > > > > -- > *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
