So you are saying that issuing the server HALT command via console is no
different than the OS level kill?

On Tue, Mar 12, 2019 at 9:15 AM Marc Lanteigne <marclantei...@ca.ibm.com>
wrote:

> 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=
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__phishing.vcu.edu_&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hMBqtRSV0jXgOdXEmlNk_-O9LHkPCGSh9PJBRSlL8Q4&m=PfoOhf0AogsmsP_PMpFEYMv80kMhcTVxSF76MpF_hsk&s=RWk9kfi3qa0PY_qgAcUA0NxmZKZ-GcJEGLyL3wfrhXk&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 http://phishing.vcu.edu/

Reply via email to