Unable to kill processes using either Ctrl-C or 'kill'
duane at nofroth.com
Sun Jun 3 18:47:35 UTC 2018
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
> 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
> $ 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/
> 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,
> 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
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe
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.
duane at nofroth.com
More information about the freebsd-questions