From owner-freebsd-questions@freebsd.org Sun Jun 3 19:48:01 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40F21FF30B7 for ; Sun, 3 Jun 2018 19:48:01 +0000 (UTC) (envelope-from jkeenan@pobox.com) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE8E378889 for ; Sun, 3 Jun 2018 19:48:00 +0000 (UTC) (envelope-from jkeenan@pobox.com) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id EB70BF20A2 for ; Sun, 3 Jun 2018 15:47:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=M3tBTgI/R4wS LfNfxOXvUuz0fF0=; b=M0twzGAPwfx4rQ+aEXsv5GZ1JfCB6OE2+n39jm22EItU S3BPebEvvCikQKTwTaFNlOE7wP+IWZqebvsHUt1nzsqCyJ1ebF1thmlgc2kd8naH fqoXQTDXghAOhumVRvCbssITvFY/6SOONkKpfBfolYmP0tqP1wol58aB4ZjxIrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=pT80mw CqK34FVj2gvpo9Bk9MIob8+73Qt9T8c60uRRzYJ8XNC0Fyw68953qe7MooO35cjS goZ1E/6wS44dpoNOuPDm0SEEVzDczCjCyfsSGj2/Sdy0VHp5I627QyLt72tCcHNT 2qDs42lESlpIXhXnFwlkOWDw1Z6HzugJth3nA= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id E28DDF20A1 for ; Sun, 3 Jun 2018 15:47:59 -0400 (EDT) Received: from [192.168.1.5] (unknown [24.185.115.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 7BFBBF20A0 for ; Sun, 3 Jun 2018 15:47:59 -0400 (EDT) Subject: Re: Unable to kill processes using either Ctrl-C or 'kill' To: freebsd-questions@freebsd.org References: <9a7f62c4-80aa-7eea-91ec-6712612a0451@pobox.com> From: James E Keenan Message-ID: <4e89e9e7-6565-290c-47a7-de7543c1a6bf@pobox.com> Date: Sun, 3 Jun 2018 15:47:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 04D8E5AC-6767-11E8-9D3F-44CE1968708C-57062903!pb-smtp1.pobox.com X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2018 19:48:01 -0000 On 06/03/2018 03:03 PM, Michael Schuster wrote: > On Sun, Jun 3, 2018 at 8:47 PM, Duane Whitty wrote: > >> On Sun, Jun 3, 2018 at 1:20 PM, James E Keenan wrote: >> >>> On a FreeBSD-11 host, I am unable to kill processes using either Ctrl-C >> or >>> 'kill'. >>> >>> 1. The problem first became manifest when I was attempting to use Vagrant >>> to download a Vagrant box from vagrantup.com. The box in question was >> a >>> VirtualBox called 'generic/freebsd11'. I have successfully downloaded, >>> installed and used this box several times already, so I anticipated no >>> problems. >>> >>> ##### >>> $ vagrant init generic/freebsd11 >>> $ vagrant up --provision | tee vagrant-up-provision.log.20180603100900 >>> Bringing machine 'default' up with 'virtualbox' provider... >>> ==> default: Checking if box 'generic/freebsd11' is up to date... >>> ==> default: Clearing any previously set forwarded ports... >>> ==> default: Fixed port collision for 22 => 2222. Now on port 2202. >>> ==> default: Clearing any previously set network interfaces... >>> ==> default: Preparing network interfaces based on configuration... >>> default: Adapter 1: nat >>> ==> default: Forwarding ports... >>> default: 22 (guest) => 2202 (host) (adapter 1) >>> ==> default: Running 'pre-boot' VM customizations... >>> ==> default: Booting VM... >>> ==> default: Waiting for machine to boot. This may take a few minutes... >>> default: SSH address: 127.0.0.1:2202 >>> default: SSH username: vagrant >>> default: SSH auth method: private key >>> ##### >>> >>> Based on recent experience, I would have expected the "few minutes" to be >>> 1 or 2 minutes at most and possibly be accompanied by "retrying" methods. >>> >>> However, at this point, the screen hung indefinitely. I tried Ctrl-C; >>> that command was printed in my terminal but otherwise nothing happened. >>> >>> 2. I ssh-ed to the host in a fresh terminal and called >>> >>> ##### >>> tail -f vagrant-up-provision.log.20180603100900 >>> ##### >>> >>> That command displayed the output posted above and hung at the same >>> point. This process also could not be killed by Ctrl-C. >>> >>> 3. I then ssh-ed to the host in a third terminal, called 'ps aux', and >>> then tried to kill suspect processes with 'kill -9 '. Those >> processes >>> were not, in fact, killed; their status was changed to 'T' -- "Marks a >>> stopped process" according to 'man ps'. Some excerpts from 'ps auxwww': >>> >>> ##### >>> vmuser 7169 0.0 0.1 81356 4444 0 T+ 14:09 0:01.99 >>> /usr/local/bin/ruby24 /usr/local/bin/vagrant up --provision >>> ... >>> jkeenan 67787 0.0 0.0 6296 0 1 WW+ - 0:00.00 >>> tail -f /home/vmuser/vagrant-images/generic-freebsd11-201806030939/ >>> vagrant-up-provision.log.20180603100900 >>> ... >>> jkeenan 74119 0.0 0.0 7064 0 2 WW+ - 0:00.00 >>> /bin/sh /usr/bin/man ps >>> ##### >>> >>> 4. I have now opened quite a few connections to the host. If I issue a >>> command there such as 'man ps' or 'less' that entails paging, I can page >>> through the output, but the process does not close by itself and does not >>> respond to Ctrl-C. If I then try to kill that process from another >>> terminal, the best that happens is that its status gets changed to 'WW+' >> -- >>> "Marks an idle interrupt thread" and "The process is swapped out". >>> >>> Internet searches turn up links like this one, >>> https://forums.freebsd.org/threads/cant-kill-process-in-the- >>> stop-state.56319/, that suggest that there are certain processes that do >>> not respond to 'kill' signals. That seems to be what's happening here. >>> >>> Can anyone suggest the cause of the problem? >>> >>> Short of requesting that the sysadmin shut down and reboot the system, is >>> there anyway for a non-root user to solve this problem? >>> >>> Thank you very much. >>> Jim Keenan >>> _______________________________________________ >>> freebsd-questions@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-questions >>> To unsubscribe, send any mail to "freebsd-questions-unsubscribe >>> @freebsd.org" >>> >> >> >> Can you get added to sudoers? I realize that still implies a level of root >> access but I really don't know of any other way to kill processes which >> don't belong to you. I don't see why the sysadmin would need to reboot. >> > > most likely, being root or equivalent won't help in this case. If a > processes owner cannot kill it (using -9, which cannot be caught) that > implies that the process is hung in the kernel (signal delivery happens > when a process leaves kernel context). > Indeed. If I say 'sudo kill -9 ', I am prompted for my password, enter it, hit Return ... and then nothing happens and I am stuck with another hung terminal.