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

[James E Keenan]

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

[Duane Whitty]

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
#####
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
_______________________________________________
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.

[Michael Schuster]

Post by James E Keenan

Post by James E Keenan
On a FreeBSD-11 host, I am unable to kill processes using either Ctrl-C

or

Post by James E Keenan
'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

Post by James E Keenan
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

Post by James E Keenan
were not, in fact, killed; their status was changed to 'T' -- "Marks a
#####
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+'

--

Post by James E Keenan
"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
_______________________________________________
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).

regards
Michael

[James E Keenan]

Post by Michael Schuster

Post by James E Keenan

Post by James E Keenan
On a FreeBSD-11 host, I am unable to kill processes using either Ctrl-C

or

Post by James E Keenan
'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

Post by James E Keenan
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

Post by James E Keenan
were not, in fact, killed; their status was changed to 'T' -- "Marks a
#####
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+'

--

Post by James E Keenan
"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
_______________________________________________
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.

[Shane Ambler]

Post by Michael Schuster
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).

I this situation, is there any way to find what function the hung
process is in? Attach and backtrace it?

While I know I can attach lldb/gdb to a running process, I can't seem to
find a way to interrupt a non-killable process to get control and see
where it is or what it is doing.

and... I just thought I should be looking at dtrace.

[Michael Schuster]

Post by Shane Ambler

Post by Michael Schuster
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).

I this situation, is there any way to find what function the hung
process is in? Attach and backtrace it?
While I know I can attach lldb/gdb to a running process, I can't seem to
find a way to interrupt a non-killable process to get control and see
where it is or what it is doing.

I don't know enough about attaching a debugger to a running process to be
able to answer this authoritatively (if that's an English word ... :-));
I'd assume that this can only happen when a process is executing in user
space or when it's returning from a system call. Since the proceiss in
question is not doing either, that probably won't work.

Post by Shane Ambler
and... I just thought I should be looking at dtrace.

DTrace works event-based. If the process that's "hung" is actually caught
in some kind of busy-waiting loop, DTrace may help you to gain some insight
into what's going on. If, OTOH, it's waiting on some synchronisation
mechanism, DTrace is probably not the tool to use here (although it may
help in establishing which kind of problem you're seeing).

HTH
Michael

[James E Keenan]

Post by Michael Schuster

Post by James E Keenan

Post by James E Keenan
On a FreeBSD-11 host, I am unable to kill processes using either Ctrl-C

or

Post by James E Keenan
'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

Post by James E Keenan
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

Post by James E Keenan
were not, in fact, killed; their status was changed to 'T' -- "Marks a
#####
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+'

--

Post by James E Keenan
"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
_______________________________________________
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).
regards
Michael

Update: While some sysadmin intervention got the hangs cleared up on
Sunday night, the problem recurred Tuesday morning. Once again, the
hang occurred during 'vagrant up' at the "Waiting for machine to boot"
point. Once again, that session refused to accept terminal input, so I
could not Ctrl-C out of it. Once again, when I logged on from another
terminal, any "vagrant xxx" command would hang -- even something as
simple as "vagrant global-status". And once again, any command that
entailed paging or interactivity would hang, e.g., 'less' would hang
when it reached EOF.

This output from 'top | cat' may support the "process is hung in the
kernel" hypothesis:

#####
$ top | cat
last pid: 23582; load averages: 0.21, 0.15, 0.10 up 39+18:08:01
13:00:49
49 processes: 1 running, 25 sleeping, 3 stopped, 4 zombie, 16 waiting

Mem: 4192K Active, 852K Inact, 56K Laundry, 7858M Wired, 42M Free
ARC: 859M Total, 332M MFU, 161M MRU, 32K Anon, 12M Header, 353M Other
234M Compressed, 588M Uncompressed, 2.51:1 Ratio
Swap: 4096M Total, 295M Used, 3801M Free, 7% Inuse


PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU
COMMAND
21147 vmuser 22 20 0 2483M 2336M select 3 32:36 0.00%
VBoxHeadless
84461 jkeenan 13 20 0 61840K 6136K select 0 27:14 0.00%
VBoxSVC
95384 jkeenan 3 20 0 2380M 2245M STOP 2 26:59 0.00%
VBoxHeadless
45500 jkeenan 23 20 0 438M 301M select 0 19:31 0.00%
VBoxHeadless
83727 jkeenan 1 20 0 20664K 4856K select 3 8:59 0.00%
VBoxXPCOMIPCD
94095 jkeenan 3 20 0 1303M 1165M STOP 1 8:41 0.00%
VBoxHeadless
...
#####

Note the high value for Wired memory. "Memory in use by the Kernel.
This memory cannot be swapped out."
(https://unix.stackexchange.com/questions/134862/what-do-the-different-memory-counters-in-freebsd-mean#137254)

I have not yet heard back from the sysadmin concerning this second
occurrence, so any suggestions you might have would be appreciated.

Thank you very much.
Jim Keenan

[Ole]

Sun, 3 Jun 2018 21:03:31 +0200 - Michael Schuster

Post by Michael Schuster

Post by Duane Whitty
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).

I got stuck in the same situation:

# 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

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.

Thanks
Ole

[Michael Schuster]

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"

for 1), all I can think of is a kernel debugger and some fairly
sophisticated twiddling of bits ...

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 ...

HTH
Michael

Post by Ole
Sun, 3 Jun 2018 21:03:31 +0200 - Michael Schuster

Post by Michael Schuster

Post by Duane Whitty
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).

# 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
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.
Thanks
Ole

[Christos Chatzaras]

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.

Post by Michael Schuster
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"
for 1), all I can think of is a kernel debugger and some fairly
sophisticated twiddling of bits ...
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 ...
HTH
Michael

Post by Ole
Sun, 3 Jun 2018 21:03:31 +0200 - Michael Schuster

Post by Michael Schuster

Post by Duane Whitty
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).

# 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
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.
Thanks
Ole

--
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-questions

[CyberLeo Kitsana]

Post by Ole
# 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
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.

This process is stopped (state T). Sending it signal 19 (SIGCONT) might
help unstick it long enough for it to receive SIGKILL.

It might be a good idea to try and figure out why it got stopped in the
first place, though.
--
Fuzzy love,
-CyberLeo

<***@CyberLeo.Net>
Technical Administrator

CyberLeo.Net Webhosting
http://www.CyberLeo.Net

Element9 Communications
http://www.Element9.net


Furry Peace! - http://www.fur.com/peace/