LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 06-24-2002, 01:04 PM   #1
Syncrm
Member
 
Registered: Aug 2001
Location: Lansing, Michigan
Distribution: slackware8+
Posts: 472

Rep: Reputation: 30
processes that can't be killed :-\


i have a strange problem on one of my slack8 boxes. i was remotely logged in, and just doing a few things and routinely typed "ls" but then my terminal froze. i had to disconnect and relogin. i noticed the ls process was still running and killed it with the usual "kill 18317". but the process is still there, so i tried "kill -SIGTERM 18317" and still it's there.

i could live with one process that was misbehaving, but whenever i type "ls" it locks my terminal and a new ls process starts that can't be killed. also whenever i try and use the TAB key my terminal freezes too and there's a -bash process in there afterwards that can't be killed.

any suggestions? i'd really hate to reboot... i've got a great uptime going. :-)
 
Old 06-24-2002, 01:10 PM   #2
neo77777
LQ Addict
 
Registered: Dec 2001
Location: Brooklyn, NY
Distribution: *NIX
Posts: 3,704

Rep: Reputation: 56
try
kill -9 PID
it is the same as
kill -KILL PID
 
Old 06-24-2002, 01:15 PM   #3
mikek147
Member
 
Registered: Mar 2002
Location: Elyria, Ohio
Distribution: Debian, Nothing else required
Posts: 141

Rep: Reputation: 15
kill pid
kill -SIGTERM pid
and
kill -15 pid

is the same command.

As neo77777 said:

kill -9 pid
and
kill -SIGKILL pid

is the same command. The difference is that -SIGTERM requests that the pid shut itself down gracefully, always perferable, where -SIGKILL tells the kernel to shut down the pid unconditionally. -mk
 
Old 06-24-2002, 01:27 PM   #4
ahmiq
LQ Newbie
 
Registered: Oct 2001
Location: 43 X-axis 65.8 Y-axis, Mars
Distribution: Redhat,Mandrake,FreeBsd, etc
Posts: 13

Rep: Reputation: 0
i got the same problem with redhat,

at tty1 a telnet session was working and running logs of remote machine,remot machine reboot in mean time and session of telnet hangup , i tried from tty2 ,3 to kill the first session ,but i saw ps auwx is not showing the telnet command ,but tty1 was hang, i tried to kill -9 pid of /sbin/mingetty tty1 (may be stupidity), but after every kill tty1 was start again but session didnt wake up

?????
 
Old 06-24-2002, 01:35 PM   #5
Syncrm
Member
 
Registered: Aug 2001
Location: Lansing, Michigan
Distribution: slackware8+
Posts: 472

Original Poster
Rep: Reputation: 30
unfortunately, i've already tried all those types of kills and none of them work. in the mean time, my box is becoming more and more cluttering with these processes... grrr!
 
Old 06-24-2002, 01:36 PM   #6
mikek147
Member
 
Registered: Mar 2002
Location: Elyria, Ohio
Distribution: Debian, Nothing else required
Posts: 141

Rep: Reputation: 15
The killing of a tty will indeed kill the process. But because of the respawn spec on the tty line in question in /etc/inittab, the getty is restarted. Not a problem, that is how it's supposed to work. If you want to shutdown a getty on a specific tty, vi into /etc/inbittab. Insert a comment character # in the first character position of the line with the tty. Exit out of vi after saving yout change, then run the command:

init q

This will force initd to re-read /etc/inittab, turning off that tty.

To turn it back on again, vi into /etc/inittab again and remove the comment character #, save and exit, then re-run

init q.

-mk
 
Old 06-24-2002, 01:41 PM   #7
Syncrm
Member
 
Registered: Aug 2001
Location: Lansing, Michigan
Distribution: slackware8+
Posts: 472

Original Poster
Rep: Reputation: 30
Quote:
Originally posted by mikek147
The killing of a tty will indeed kill the process. But because of the respawn spec on the tty line in question in /etc/inittab, the getty is restarted. Not a problem, that is how it's supposed to work. If you want to shutdown a getty on a specific tty, vi into /etc/inbittab. Insert a comment character # in the first character position of the line with the tty. Exit out of vi after saving yout change, then run the command:

init q

This will force initd to re-read /etc/inittab, turning off that tty.

To turn it back on again, vi into /etc/inittab again and remove the comment character #, save and exit, then re-run

init q.
but what if you're logged in via ssh or telnet and not tty?
 
Old 06-24-2002, 02:28 PM   #8
JaseP
Senior Member
 
Registered: Jun 2002
Location: Eastern PA, USA
Distribution: K/Ubuntu 18.04-14.04, Scientific Linux 6.3-6.4, Android-x86, Pretty much all distros at one point...
Posts: 1,802

Rep: Reputation: 157Reputation: 157
Well, there are some things that should/can be only done locally...
 
Old 06-24-2002, 02:33 PM   #9
mikek147
Member
 
Registered: Mar 2002
Location: Elyria, Ohio
Distribution: Debian, Nothing else required
Posts: 141

Rep: Reputation: 15
A telnet session over the network opens a pts# port, rather than a tty. In this case, using a ps -ef will give both a pid and ppid, porcess id and a parent process id.

Say you had a user called sam, and sam logged in from some remote site through telnet. If you did a ps -ef | grep sam, you will see a ps listing of first the user, sam, followed by the pid and ppid. If you look at the ppid, now matter what sam is doing, you can follow the ppid back to the pid where he logged in, which might look something like:

Quote:
telnetd 2719 711 0 14:56 ? 00:00:00 in.telnetd: 10.213.32.36
sam 2720 2719 0 14:56 pts/2 00:00:00 -bash
sam 2969 2720 0 15:21 pts/2 00:00:00 ps -ef
sam 2970 2720 0 15:21 pts/2 00:00:00 grep sam
The above is really 2 ps -ef | grep operations. The first one was a grep on sam, the second was a grep on the ppid, 2719, from the -bash entry. The second one was a grep on 2719, which was the pid for the telnet successful login which started the bash shell. So, worst case you may have to kill a few entries in order to clear everything out of your process stack.

Keep in mind that when you want to trace out the pid audit trail of a login, use ps -ef, not ps -auwx. -mk
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
I Killed It HELP Kwestion SUSE / openSUSE 1 10-23-2005 01:54 AM
killed libc-2.5.5.so need help wolfe2554 Debian 1 02-09-2005 01:08 PM
monitoring active processes and identifying the required processes. gajaykrishnan Programming 2 08-13-2004 01:58 AM
killed artsd, now what? Scruff Linux - Software 4 09-05-2003 12:03 AM
User processes not killed on exit ugenn Linux - General 5 04-25-2002 02:19 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 07:32 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration