Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

kill -9

6 posts in Product Futures Discussion Last posting was on 2002-04-05 21:20:45.0Z
Matt Posted on 2002-04-05 05:29:06.0Z
From: "Matt" <matt@fanhome.com>
Subject: kill -9
Date: Fri, 5 Apr 2002 00:29:06 -0500
Lines: 17
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Message-ID: <OmzIrJG3BHA.206@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: dhcp16469119.woh.rr.com 24.164.69.119
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:557
Article PK: 94084

When I kill a process, I sure as heck mean 'kill'! If a process is
sleeping -- more power to it, except maybe I want to shutdown the ASE and
not do 'with nowait' but can't since a single (user) process is doing
something weird even though I shut off the front-end (and no it wasn't my
instance ;)).

I'd like functionality to *really kill* a process, no matter what it is
doing. Certainly if ASE is managing its own processes it should more than
be able to kill one, so I can only think the functionality is being withheld
for some reason. If the process is currently running a transaction then I'd
expect it would either a) be rolled back or b) killed (e.g. with no thought
given to commiting / rolling back, simply remove from x-act log).

--
Matt


Dan Thrall Posted on 2002-04-05 21:20:45.0Z
From: "Dan Thrall" <dthrall@sybase.com>
References: <OmzIrJG3BHA.206@forums.sybase.com>
Subject: Re: kill -9
Date: Fri, 5 Apr 2002 14:20:45 -0700
Lines: 39
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Message-ID: <kr7sHiO3BHA.186@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: 157.133.215.130
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:552
Article PK: 93720

When a spid is killed and is on the cpu, it will be killed. For those
"unkillable" spids, they cannot be killed likely because they are sleeping.
Since they aren't taking any cpu time, they have no idea that they are being
killed :-) The same is true for unix too.

Once you issue a kill command on a sleeping process, we set a bit on the
process so that if and when it wakes up, it will be killed. There was a fix
placed into 12.5.0.1 and 12.0.0.3 ESD 4 and up where you can kill a spid
that is hanging in "remote i/o."
Taken from the coverletter:
255461 "A process which hangs when connected to, or when connecting to a
remote back end cannot be killed."

Dan

"Matt" <matt@fanhome.com> wrote in message
news:OmzIrJG3BHA.206@forums.sybase.com...
> When I kill a process, I sure as heck mean 'kill'! If a process is
> sleeping -- more power to it, except maybe I want to shutdown the ASE and
> not do 'with nowait' but can't since a single (user) process is doing
> something weird even though I shut off the front-end (and no it wasn't my
> instance ;)).
>
> I'd like functionality to *really kill* a process, no matter what it is
> doing. Certainly if ASE is managing its own processes it should more than
> be able to kill one, so I can only think the functionality is being
withheld
> for some reason. If the process is currently running a transaction then
I'd
> expect it would either a) be rolled back or b) killed (e.g. with no
thought
> given to commiting / rolling back, simply remove from x-act log).
>
> --
> Matt
>
>


Shane_Glasheen Posted on 2002-04-05 06:13:01.0Z
From: Shane_Glasheen
Date: Fri, 5 Apr 2002 02:13:01 -0400
Newsgroups: sybase.public.ase.product_futures_discussion
Subject: Re: kill -9
Message-ID: <08C2046E2A664B7E0022269285256B92.002069E385256B92@webforums>
References: <OmzIrJG3BHA.206@forums.sybase.com>
Lines: 18
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com!webforums.sybase.com!news
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:556
Article PK: 93735

interesting question.... previous versions of Sybase had an
undocumented command to kill off a Sybase SPID regardless of
what it was doing - however, if often ended in database
corruption.

these days (ASE 12, 12.5) it seems much better and nearly all
SPID's are able to be killed off with the normal Sybase kill
command.

the only one's we've had problems with lately are CIS zombie
processes and remote I/O hanging issues, which are being
resolved in up-coming SWR's.


Shane

> I'd like functionality to *really kill* a process, no matter >what it is
>doing.


Matt Posted on 2002-04-05 09:56:13.0Z
From: "Matt" <matt@fanhome.com>
References: <OmzIrJG3BHA.206@forums.sybase.com> <08C2046E2A664B7E0022269285256B92.002069E385256B92@webforums>
Subject: Re: kill -9
Date: Fri, 5 Apr 2002 04:56:13 -0500
Lines: 36
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Message-ID: <gXvc8eI3BHA.186@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: dhcp16469119.woh.rr.com 24.164.69.119
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:555
Article PK: 93723

Shane,

I agree, the majority of the time there's nothing wrong with the current
implementation.. However there was this *one* time in which we had a
sleeping process sit there... and sit there... for something several hours
in our maintenance window in which we wanted to offline the DB and apply an
EBF. Of course we couldn't since the process would never DIE, so if I
recall correctly we had to shutdown with nowait, which I think would have
been a lot more painful than killing a sleeping user process which for some
reason got 'stuck'.

--
Matt

<Shane_Glasheen> wrote in message
news:08C2046E2A664B7E0022269285256B92.002069E385256B92@webforums...
>
> interesting question.... previous versions of Sybase had an
> undocumented command to kill off a Sybase SPID regardless of
> what it was doing - however, if often ended in database
> corruption.
>
> these days (ASE 12, 12.5) it seems much better and nearly all
> SPID's are able to be killed off with the normal Sybase kill
> command.
>
> the only one's we've had problems with lately are CIS zombie
> processes and remote I/O hanging issues, which are being
> resolved in up-coming SWR's.
>
> Shane
>
> > I'd like functionality to *really kill* a process, no matter >what it is
> >doing.


Pablo Sanchez Posted on 2002-04-05 15:35:05.0Z
From: "Pablo Sanchez" <pablo@dev.null>
References: <OmzIrJG3BHA.206@forums.sybase.com> <08C2046E2A664B7E0022269285256B92.002069E385256B92@webforums> <gXvc8eI3BHA.186@forums.sybase.com>
Subject: Re: kill -9
Date: Fri, 5 Apr 2002 08:35:05 -0700
Lines: 29
Organization: High-Performance Database Engineering
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <xqCmTiL3BHA.133@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: 207.225.105.222
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:554
Article PK: 93726


"Matt" <matt@fanhome.com> wrote in message
news:gXvc8eI3BHA.186@forums.sybase.com...
> Shane,
>
> I agree, the majority of the time there's nothing wrong with the
current
> implementation.. However there was this *one* time in which we had a
> sleeping process sit there... and sit there... for something several
hours
> in our maintenance window in which we wanted to offline the DB and
apply an
> EBF. Of course we couldn't since the process would never DIE, so if
I
> recall correctly we had to shutdown with nowait, which I think would
have
> been a lot more painful than killing a sleeping user process which
for some
> reason got 'stuck'.

I think if you would have issued a 'checkpoint' in all the DB's, then
did a 'nowait' (or a kill -15 to dataserver -- ouch!) it wouldn't have
been too bad.
--
Pablo Sanchez, High-Performance Database Engineering
mailto:pablo@hpdbe.com
Available for short-term and long-term contracts


Matt Posted on 2002-04-05 21:16:01.0Z
From: "Matt" <matt@fanhome.com>
References: <OmzIrJG3BHA.206@forums.sybase.com> <08C2046E2A664B7E0022269285256B92.002069E385256B92@webforums> <gXvc8eI3BHA.186@forums.sybase.com> <xqCmTiL3BHA.133@forums.sybase.com>
Subject: Re: kill -9
Date: Fri, 5 Apr 2002 16:16:01 -0500
Lines: 19
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Message-ID: <j9Nm0aO3BHA.186@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: dhcp16469119.woh.rr.com 24.164.69.119
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:553
Article PK: 93722

We didn't end up with any corruption (knock on wood never have :)) but we
*did* have massive identity gaps. That could be solved by allowing me to
axe the process then shutdown >go. This was in 11.9.2 before ident_gap
management didn't suck.

--
Matt

"Pablo Sanchez" <pablo@dev.null> wrote in message
news:xqCmTiL3BHA.133@forums.sybase.com...
> I think if you would have issued a 'checkpoint' in all the DB's, then
> did a 'nowait' (or a kill -15 to dataserver -- ouch!) it wouldn't have
> been too bad.
> --
> Pablo Sanchez, High-Performance Database Engineering
> mailto:pablo@hpdbe.com
> Available for short-term and long-term contracts