Date: Mon, 11 Jun 2018 12:29:22 +0300 From: Christos Chatzaras <chris@cretaforce.gr> To: FreeBSD <freebsd-questions@freebsd.org> Subject: Re: Unable to kill processes using either Ctrl-C or 'kill' Message-ID: <7E248F42-B2B7-4683-814C-E9100F25EAF3@cretaforce.gr> In-Reply-To: <CADqw_g%2B4g71Q3rFu959coCVrHTtwJzJ-hk604riWsmCwtVX96Q@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> <20180611104857.272ba600.ole@free.de> <CADqw_g%2B4g71Q3rFu959coCVrHTtwJzJ-hk604riWsmCwtVX96Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
We had the same (or similar problem) problem with FreeBSD 10.3 and = creating big archives with tar sometimes was making the tar process to = hang and kill -9 was not able to stop the process. This bug was fixed in = FreeBSD 10-STABLE. > On 11 Jun 2018, at 12:03, Michael Schuster <michaelsprivate@gmail.com> = wrote: >=20 > I can think of two ways a process/thread gets "stuck" in the kernel > 1) it's waiting for some kind of lock/resource to get released > 2) like 1, but doing so "busy waiting" >=20 > for 1), all I can think of is a kernel debugger and some fairly > sophisticated twiddling of bits ... >=20 > in the second case, the system's load is probably quite high, and you = may > be able to find out what it's doing using dtrace and a profile = provider ... >=20 > HTH > Michael >=20 > On Mon, Jun 11, 2018 at 10:50 AM Ole <ole@free.de> wrote: >=20 >> Sun, 3 Jun 2018 21:03:31 +0200 - Michael Schuster >> <michaelsprivate@gmail.com>: >>=20 >>>> 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. >>>=20 >>> 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). >>=20 >> I got stuck in the same situation: >>=20 >> # kill -9 91651 >> # ps -o pid,jid -awux | grep 91651 >> 91651 11 root 0.0 0.0 101488 29344 - TsJ Fri05 >> 2:10.18 /usr/local/sbin/syslog-ng -p /var/run/syslog.pid >>=20 >> and I wonder if there is anything I can do to get rid of this = process. >> I had this situation last year too and ended up in restarting the = whole >> system. But now I can't reboot. >>=20 >> Thanks >> Ole >>=20 >=20 >=20 > --=20 > Michael Schuster > http://recursiveramblings.wordpress.com/ > recursion, n: see 'recursion' > _______________________________________________ > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7E248F42-B2B7-4683-814C-E9100F25EAF3>