That's what I said. > From the /etc/init.d/tsminst1 wrapper script, it does do a kill > command, but without any signal, which means it defaults to -15 > (SIGTERM). That sends a message to the process to shutdown gracefully.
It's in the manual as one of the proper ways to start/stop the server: https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.0/srv.install/t_srv_startsrv_autolnx-linux.html If the wrapper was doing a "kill -9", that would be a completely different ball of wax. - Thanks, Marc... ________________________________________________________ Marc Lanteigne Spectrum Protect Specialist AVP / SRT \ -----Original Message----- From: Zoltan Forray <zfor...@vcu.edu> Sent: Tuesday, March 12, 2019 10:04 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] best way to avoid long rollback tsminst1 is a script in /etc/rc.d/init.d which determines the pid of the running dsmserv process and then issues a kill against it. From the tsminst1 script stop() { echo "Stopping $prog instance $instance ..." if [[ -e $pidfile ]] then # make sure someone else didn't kill us already progpid=`cat $pidfile` running=`ps -ef | grep $prog | grep -w $progpid | grep -v grep` if [[ -n $running ]] then #echo "executing cmd kill `cat $pidfile`" * kill `cat $pidfile`* total_slept=0 while check_running; do \ echo "$prog instance $instance still running, will check after $SLEEP_INTERVAL seconds" sleep $SLEEP_INTERVAL total_slept=`expr $total_slept + 1` On Tue, Mar 12, 2019 at 7:57 AM Marc Lanteigne <marclantei...@ca.ibm.com> wrote: > "systemctl stop tsminst1" is not a kill. That's a service command to tell > the application it manages to shut down gracefully. > > From the KC: > > https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.0/srv.install/t > _srv_startsrv_autolnx-linux.html > > 6. To start or stop the server, issue one of the following commands: > To start the server: > service tsminst1 start > > To stop the server: > service tsminst1 stop > > From the /etc/init.d/tsminst1 wrapper script, it does do a kill > command, but without any signal, which means it defaults to -15 > (SIGTERM). That sends a message to the process to shutdown gracefully. > > - > Thanks, > Marc... > ________________________________________________________ > Marc Lanteigne > Spectrum Protect Specialist AVP / SRT > 416.478.0233 | marclantei...@ca.ibm.com Office Hours: Monday to > Friday, 7:00 to 16:00 Eastern > > Latest Servermon for Spectrum Protect: > http://www-01.ibm.com/support/docview.wss?uid=swg21432937 > Performance Mustgather for Spectrum Protect: > http://www-01.ibm.com/support/docview.wss?uid=swg22013355 > Spectrum Protect Blueprint: > https://urldefense.proofpoint.com/v2/url?u=https-3A__ibm.biz_BdHc6b&d= > DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hMBqtRSV0jXgOdXEmlNk_-O9LHkPCGSh9PJB > RSlL8Q4&m=PfoOhf0AogsmsP_PMpFEYMv80kMhcTVxSF76MpF_hsk&s=LwtR0_gcb0BG2- > HKfoR-2RTOuld1nkMKkRqYJJzzdNg&e= > > Follow me on: Twitter, developerWorks, LinkedIn > > > > -----Original Message----- > From: Zoltan Forray <zfor...@vcu.edu> > Sent: Monday, March 11, 2019 01:52 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] best way to avoid long rollback > > Out of curiosity, why do you do a "systemctl stop tsminst1" (which if > I recall does a kill) vs just HALT the ISP server immediately after > the DB backup finishes? Our patching takes about the same time (we do > it monthly) since the IBM lin_tape drivers have to be removed before > kernel patching and then reinstalled afterwards which adds to the time. > > On Mon, Mar 11, 2019 at 12:38 PM J. Eric Wonderley > <eric.wonder...@vt.edu> > wrote: > > > We are running rhel7 on a dell r730 and we just did a full and > > dbsnap...ususally take about 1.5h for both to complete. > > > > Typically then shutdown with systemctl stop tsminst1. > > > > I think last time we stopped tsm about an hour after the db finished > > its backups. Likely restarted tsm about an hour after tsm stopped. > > It takes roughly and an hour for us to do all of the patching > > tripwire reboot etc that we do. > > > > On Mon, Mar 11, 2019 at 12:19 PM Zoltan Forray <zfor...@vcu.edu> wrote: > > > > > I have to ask what OS/hardware/ISP are you running? What > > > procedure are > > you > > > using to prep for the OS patching (we stop client sessions/all > > > admin processes - do a full DB backup - halt the server) > > > > > > Our offsite replica server is RHEL 7 on Dell R740xd with 192GB and > > > 3TB > > SSD > > > with the DB currently at 2.3TB used. We patch monthly and never > > > had it take more than 15-minutes from OS reboot to ISP server > > > being > available! > > > > > > On Mon, Mar 11, 2019 at 11:41 AM J. Eric Wonderley < > > eric.wonder...@vt.edu> > > > wrote: > > > > > > > We have a pair of tsm servers doing backup and replication. > > > > Each has a database over 1TB on ssd and 512G of memory > > > > > > > > Our organization likes to do os patch maintenance every 90d and > > > > doing > > > this > > > > requires a stop and restart of db2. When would it be best to do > > > > maintenance to shorten the rollback time? > > > > > > > > I would think after completing the db backups. Last time we did > > > > maintenance about 1h after backups completed it took >2h for the > > > > db to > > > come > > > > up. > > > > > > > > Thanks > > > > > > > > > > > > > -- > > > *Zoltan Forray* > > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > > > Xymon Monitor Administrator VMware Administrator Virginia > > > Commonwealth University UCC/Office of Technology Services > > > www.ucc.vcu.edu 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 > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__phishing.vcu.e > > > du > > > _&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hMBqtRSV0jXgOdXEmlNk_-O9LHkP > > > CG > > > Sh9PJBRSlL8Q4&m=F_EEf1krKkfXHfk6n1Ly1R4pJGcAd7jIzS0Gsls-pbM&s=nAAT > > > GI _Luo77W-RZpuAQ8uLoaF0ODjnjGZX4Li4bSE8&e= > > > > > > > > -- > *Zoltan Forray* > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon > Monitor Administrator VMware Administrator Virginia Commonwealth > University UCC/Office of Technology Services www.ucc.vcu.edu > 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 > > https://urldefense.proofpoint.com/v2/url?u=http-3A__phishing.vcu.edu_&; > d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hMBqtRSV0jXgOdXEmlNk_-O9LHkPCGSh9P > JBRSlL8Q4&m=F_EEf1krKkfXHfk6n1Ly1R4pJGcAd7jIzS0Gsls-pbM&s=nAATGI_Luo77 > W-RZpuAQ8uLoaF0ODjnjGZX4Li4bSE8&e= > -- *Zoltan Forray* Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor Administrator VMware Administrator Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__phishing.vcu.edu_&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hMBqtRSV0jXgOdXEmlNk_-O9LHkPCGSh9PJBRSl L8Q4&m=PfoOhf0AogsmsP_PMpFEYMv80kMhcTVxSF76MpF_hsk&s=RWk9kfi3qa0PY_qgAcUA0NxmZKZ-GcJEGLyL3wfrhXk&e=
