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

[Duane Whitty]

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.

-- 
Best Regards,
Duane

Duane Whitty
duane at nofroth.com