Reply
 
LinkBack Thread Tools Display Modes
  #1   Report Post  
Old December 30th 03, 03:19 PM
Dr. David Kirkby
 
Posts: n/a
Default 'crafty' took ages to kill

Sorry for the cross-posting to two quite different newsgroups, but it
seems appropiate in the circumstances.

'crafty' is a well known chess program that can run on UNIX machines.
I've just spent quite a while trying to 'kill' an unwanted 'crafty'
process running on my UNIX worksation, which I noticed had eaten up
some 61 hours of CPU time. Despite

% kill pid

then when that failed


% kill -9 pid

a couple of times, it would not die. Finally after about 5 kill -9's
the process died. Has anyone seen this before? I'm running a Sun Ultra
80 workstation, Solaris 9, 4 x 450 MHz CPUs, 4 GB RAM, crafty 19.7
built for multi-threaded operation.

What can stop a process responding to SIGKILL ?? Since there were two
copies of this process running (one intentional, one not intenstional)
each configured to use 4 CPUs, the load average was about 8, but that
should not be excessive for a quad processor machine. The machine did
not appear under any strain, and interactive peformance was fine, so
I'm a bit puzzled why this should happen.

I've seen similar things before on a Sun and once a reboot was
required. I'm just not quite sure how it can occur.

As usual, my email address can be found at
http://atlc.sourceforge.net/contact.html
should anyone choose to email me, although the newsgroup is probably a
better place for a response.
  #2   Report Post  
Old December 30th 03, 05:13 PM
Lyle Merdan
 
Posts: n/a
Default 'crafty' took ages to kill

In comp.sys.sun.admin Dr. David Kirkby m wrote:
: Sorry for the cross-posting to two quite different newsgroups, but it
: seems appropiate in the circumstances.

: 'crafty' is a well known chess program that can run on UNIX machines.
: I've just spent quite a while trying to 'kill' an unwanted 'crafty'
: process running on my UNIX worksation, which I noticed had eaten up
: some 61 hours of CPU time. Despite

: % kill pid

: then when that failed


: % kill -9 pid

: a couple of times, it would not die. Finally after about 5 kill -9's
: the process died. Has anyone seen this before? I'm running a Sun Ultra
: 80 workstation, Solaris 9, 4 x 450 MHz CPUs, 4 GB RAM, crafty 19.7
: built for multi-threaded operation.

: What can stop a process responding to SIGKILL ?? Since there were two
: copies of this process running (one intentional, one not intenstional)
: each configured to use 4 CPUs, the load average was about 8, but that
: should not be excessive for a quad processor machine. The machine did
: not appear under any strain, and interactive peformance was fine, so
: I'm a bit puzzled why this should happen.

: I've seen similar things before on a Sun and once a reboot was
: required. I'm just not quite sure how it can occur.

: As usual, my email address can be found at
: http://atlc.sourceforge.net/contact.html
: should anyone choose to email me, although the newsgroup is probably a
: better place for a response.

If a kill -9 doesn't zap a process I usuall try kill -XCPU and that
will many times do the trick.

Lyle
  #5   Report Post  
Old December 31st 03, 02:48 AM
Robert Hyatt
 
Posts: n/a
Default 'crafty' took ages to kill

In rec.games.chess.computer Dr. David Kirkby m wrote:
Sorry for the cross-posting to two quite different newsgroups, but it
seems appropiate in the circumstances.


'crafty' is a well known chess program that can run on UNIX machines.
I've just spent quite a while trying to 'kill' an unwanted 'crafty'
process running on my UNIX worksation, which I noticed had eaten up
some 61 hours of CPU time. Despite


% kill pid


then when that failed



% kill -9 pid


a couple of times, it would not die. Finally after about 5 kill -9's
the process died. Has anyone seen this before? I'm running a Sun Ultra
80 workstation, Solaris 9, 4 x 450 MHz CPUs, 4 GB RAM, crafty 19.7
built for multi-threaded operation.


Most likely you had a large hash table setting. The original kill
command probably caused Crafty to crash, which will then write a .core
file. With a big hash, egtb cache, egtb decompression indices, you can
get a .core file that will choke a large mule...

Otherwise no idea as a process can _never_ ignore kill -9...


What can stop a process responding to SIGKILL ?? Since there were two
copies of this process running (one intentional, one not intenstional)
each configured to use 4 CPUs, the load average was about 8, but that
should not be excessive for a quad processor machine. The machine did
not appear under any strain, and interactive peformance was fine, so
I'm a bit puzzled why this should happen.


I've seen similar things before on a Sun and once a reboot was
required. I'm just not quite sure how it can occur.


I don't see this on linux so I am not sure, but the most common problem
is the huge core file that can take forever to write, particularly if you
are using NFS for your directory.

As usual, my email address can be found at
http://atlc.sourceforge.net/contact.html
should anyone choose to email me, although the newsgroup is probably a
better place for a response.


--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170


  #6   Report Post  
Old December 31st 03, 02:49 AM
Robert Hyatt
 
Posts: n/a
Default 'crafty' took ages to kill

In rec.games.chess.computer Lyle Merdan wrote:

If a kill -9 doesn't zap a process I usuall try kill -XCPU and that
will many times do the trick.


Lyle


-XCPU is "softer" than -9 (SIGKILL). That just reports "CPU time
exceeded" but the process can still run a bit longer...

--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170
  #7   Report Post  
Old January 2nd 04, 09:37 PM
Dr. David Kirkby
 
Posts: n/a
Default 'crafty' took ages to kill

Robert Hyatt wrote in message ...
'crafty' is a well known chess program that can run on UNIX machines.
I've just spent quite a while trying to 'kill' an unwanted 'crafty'
process running on my UNIX worksation, which I noticed had eaten up
some 61 hours of CPU time. Despite


% kill pid


then when that failed



% kill -9 pid


a couple of times, it would not die. Finally after about 5 kill -9's
the process died. Has anyone seen this before? I'm running a Sun Ultra
80 workstation, Solaris 9, 4 x 450 MHz CPUs, 4 GB RAM, crafty 19.7
built for multi-threaded operation.


Most likely you had a large hash table setting. The original kill
command probably caused Crafty to crash, which will then write a .core
file. With a big hash, egtb cache, egtb decompression indices, you can
get a .core file that will choke a large mule...

Yes I did have large hash table settings - probably 500 Mb or more for
hash and hasp. However, /etc/system contains the line:

set sys:coredumpsize 0

which should prevent coredumps being produced - I do that for
securetiy reasons.

Otherwise no idea as a process can _never_ ignore kill -9...
I don't see this on linux so I am not sure, but the most common problem
is the huge core file that can take forever to write, particularly if you
are using NFS for your directory.


I don't normally on Solaris, but on this occasion I did. It's a long
time since I've seen this behaviour under Solaris ( 1 year), but I
must admit I have seen it before.

Am I right in assuming crafty does not use any form of kernal locking
on Solaris, but just pthreads for SMP support?

Dr. David Kirkby
email address at: http://atlc.sourceforge.net/contact.html
  #8   Report Post  
Old January 2nd 04, 09:58 PM
Robert Hyatt
 
Posts: n/a
Default 'crafty' took ages to kill

In rec.games.chess.computer Dr. David Kirkby m wrote:
Robert Hyatt wrote in message ...
'crafty' is a well known chess program that can run on UNIX machines.
I've just spent quite a while trying to 'kill' an unwanted 'crafty'
process running on my UNIX worksation, which I noticed had eaten up
some 61 hours of CPU time. Despite


% kill pid


then when that failed



% kill -9 pid


a couple of times, it would not die. Finally after about 5 kill -9's
the process died. Has anyone seen this before? I'm running a Sun Ultra
80 workstation, Solaris 9, 4 x 450 MHz CPUs, 4 GB RAM, crafty 19.7
built for multi-threaded operation.


Most likely you had a large hash table setting. The original kill
command probably caused Crafty to crash, which will then write a .core
file. With a big hash, egtb cache, egtb decompression indices, you can
get a .core file that will choke a large mule...

Yes I did have large hash table settings - probably 500 Mb or more for
hash and hasp. However, /etc/system contains the line:


set sys:coredumpsize 0


which should prevent coredumps being produced - I do that for
securetiy reasons.


Otherwise no idea as a process can _never_ ignore kill -9...
I don't see this on linux so I am not sure, but the most common problem
is the huge core file that can take forever to write, particularly if you
are using NFS for your directory.


I don't normally on Solaris, but on this occasion I did. It's a long
time since I've seen this behaviour under Solaris ( 1 year), but I
must admit I have seen it before.


Am I right in assuming crafty does not use any form of kernal locking
on Solaris, but just pthreads for SMP support?


Yes. It does use the mutex pthread_lock() stuff of course, for
critical sections in the SMP code. No idea what else might cause a
slow termination...


Dr. David Kirkby
email address at: http://atlc.sourceforge.net/contact.html


--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170
  #9   Report Post  
Old January 3rd 04, 07:37 AM
Anders Thulin
 
Posts: n/a
Default 'crafty' took ages to kill

Dr. David Kirkby wrote:

Yes I did have large hash table settings - probably 500 Mb or more for
hash and hasp. However, /etc/system contains the line:

set sys:coredumpsize 0

which should prevent coredumps being produced - I do that for
securetiy reasons.


Sorry -- not chess oriented, but perhaps of use for the the other group:

It won't do you any good: coredumpsize is not a valid kernel variable,
and there has not been any kernel module called sys since at least
Solaris 2. So it won't do anything. (Yes, there are Sun documents that
claim it should be used, but they are wrong.)

Use coreadm instead.

See http://dbforums.com/arch/128/2002/7/426204 for my sources.

--
Anders Thulin http://www.algonet.se/~ath

  #10   Report Post  
Old January 3rd 04, 11:04 AM
Casper H.S. Dik
 
Posts: n/a
Default 'crafty' took ages to kill

(Dr. David Kirkby) writes:

set sys:coredumpsize 0


which should prevent coredumps being produced - I do that for
securetiy reasons.


That line in /etc/system has no effect; and it never had any effect
either.

I know that it has been documented in some documents, even some originating
from Sun; but it never was a Solaris tunable.

The reason why the tunable gives no error either is fairly simple: as
long as the module "sys" isn't loaded, the kernel doesn't know that
there's no "sys'coredumpsize" tunable. Since there's no module "sys" the
error is never detected. (There never was a Solaris module called "sys"
either; and I've checked all source code back to Solaris 2.0 so I
*know* that this is a statement of fact)

I supposed that computers have progressed to the point that they're
sufficiently magic to warrant prayer-like command sequences and configuration
options, but I degress.

You will need to use "coreadm" to limit core dumps or redirect them,
on sufficiently recent Solaris versions. (Solaris 7 with kernel patch rev
106541-06 (sparc) or 106542-06 (intel) and later or later Solaris releases)

I don't normally on Solaris, but on this occasion I did. It's a long
time since I've seen this behaviour under Solaris ( 1 year), but I
must admit I have seen it before.


Coredumps could still be an issue considering the above.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Reply
Thread Tools
Display Modes

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Crafty SMP question John Cordes rec.games.chess.computer (Computer Chess) 0 September 17th 03 06:19 PM
Crafty Move List Christopher rec.games.chess.computer (Computer Chess) 2 July 25th 03 09:27 PM
crafty coding alternate line Christopher rec.games.chess.computer (Computer Chess) 1 July 25th 03 07:20 PM
Crafty personal Server? Christopher rec.games.chess.computer (Computer Chess) 0 July 18th 03 05:29 PM
Crafty Learning Robert Hyatt rec.games.chess.computer (Computer Chess) 0 July 9th 03 08:44 PM


All times are GMT +1. The time now is 06:02 AM.

Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright 2004-2019 ChessBanter.
The comments are property of their posters.
 

About Us

"It's about Chess"

 

Copyright © 2017