Linux - GeneralThis 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
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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. :-)
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
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
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!
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
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?
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.