Skip site navigation (1)Skip section navigation (2)
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+4g71Q3rFu959coCVrHTtwJzJ-hk604riWsmCwtVX96Q@mail.gmail.com>
References:  <9a7f62c4-80aa-7eea-91ec-6712612a0451@pobox.com> <CAOZUxFu7LkafvT30H_ZZG6uJ-CkU537RD=dSHcEP=UVRgOdrZw@mail.gmail.com> <CADqw_gLwsSKT3w8iyY7d9+isqyt7YH4CvifRL2WG54OQdvK7Xw@mail.gmail.com> <20180611104857.272ba600.ole@free.de> <CADqw_g+4g71Q3rFu959coCVrHTtwJzJ-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: <http://docs.FreeBSD.org/cgi/mid.cgi?7E248F42-B2B7-4683-814C-E9100F25EAF3>