Date: Sun, 3 Jun 2018 15:47:58 -0400 From: James E Keenan <jkeenan@pobox.com> To: freebsd-questions@freebsd.org Subject: Re: Unable to kill processes using either Ctrl-C or 'kill' Message-ID: <4e89e9e7-6565-290c-47a7-de7543c1a6bf@pobox.com> In-Reply-To: <CADqw_gLwsSKT3w8iyY7d9%2Bisqyt7YH4CvifRL2WG54OQdvK7Xw@mail.gmail.com> References: <9a7f62c4-80aa-7eea-91ec-6712612a0451@pobox.com> <CAOZUxFu7LkafvT30H_ZZG6uJ-CkU537RD=dSHcEP=UVRgOdrZw@mail.gmail.com> <CADqw_gLwsSKT3w8iyY7d9%2Bisqyt7YH4CvifRL2WG54OQdvK7Xw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/03/2018 03:03 PM, Michael Schuster wrote: > On Sun, Jun 3, 2018 at 8:47 PM, Duane Whitty <duane@nofroth.com> wrote: > >> On Sun, Jun 3, 2018 at 1:20 PM, James E Keenan <jkeenan@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4e89e9e7-6565-290c-47a7-de7543c1a6bf>