Unable to kill processes using either Ctrl-C or 'kill'

[James E Keenan]

On 06/03/2018 03:03 PM, Michael Schuster wrote:
> On Sun, Jun 3, 2018 at 8:47 PM, Duane Whitty <duane at nofroth.com> wrote:
> 
>> On Sun, Jun 3, 2018 at 1:20 PM, James E Keenan <jkeenan at pobox.com> 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 <pid>'.  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 at 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 <one-of-the-vagrant-pids>', I am 
prompted for my password, enter it, hit Return ... and then nothing 
happens and I am stuck with another hung terminal.