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://ibm.biz/BdHc6b
>
> 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.edu
> > > _&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hMBqtRSV0jXgOdXEmlNk_-O9LHkPCG
> > > Sh9PJBRSlL8Q4&m=F_EEf1krKkfXHfk6n1Ly1R4pJGcAd7jIzS0Gsls-pbM&s=nAATGI
> > > _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_-O9LHkPCGSh9PJBRSlL8Q4&m=F_EEf1krKkfXHfk6n1Ly1R4pJGcAd7jIzS0Gsls-pbM&s=nAATGI_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 http://phishing.vcu.edu/
