5

Any time I attempt to run the ps command or another similar command in a way that would make it output the arguments for any process, the command runs and produces output, but then freezes, entering an 'uninterruptible sleep' state that never exits.

Currently, I have 17 of these frozen processes still just sitting there (excerpted from top -u $USER):

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 8807 foo_user  20   0   28912   2984   2680 D   0.0  0.0   0:00.10 ps
14040 foo_user  20   0   29124   3108   2796 D   0.0  0.0   0:00.14 ps
14342 foo_user  20   0   28912   2972   2668 D   0.0  0.0   0:00.10 ps
15528 foo_user  20   0   28912   3028   2724 D   0.0  0.0   0:00.10 ps
16677 foo_user  20   0   28912   2992   2692 D   0.0  0.0   0:00.11 ps
18723 foo_user  20   0   28912   3000   2696 D   0.0  0.0   0:00.12 ps
19427 foo_user  20   0   29124   3080   2772 D   0.0  0.0   0:00.14 ps
19587 foo_user  20   0   29124   3108   2804 D   0.0  0.0   0:00.08 ps
19917 foo_user  20   0   29124   3056   2748 D   0.0  0.0   0:00.08 ps
20267 foo_user  20   0   29124   3056   2760 D   0.0  0.0   0:00.10 ps
20566 foo_user  20   0   29124   1604   1412 D   0.0  0.0   0:00.09 ps
21189 foo_user  20   0   28912   2940   2648 D   0.0  0.0   0:00.10 ps
21296 foo_user  20   0   28912   1524   1332 D   0.0  0.0   0:00.10 ps
21674 foo_user  20   0   28840   3208   2648 D   0.0  0.0   0:00.07 pgrep
26220 foo_user  20   0   28912   2968   2672 D   0.0  0.0   0:00.10 ps

Aside from the pgrep, all of these were originally started in ssh sessions from bash shells; I've since manually killed the sshd and bash processes, but the child ps processes remain. The pgrep, pid 21674, was the result of me pressing c inside top to try to list the command line arguments that way — resulting in top also freezing while waiting for the pgrep output.

I've ruled out the possibility that there's some running process whose arguments are somehow "dirty" (too long? contains control characters?) and causing this, because the freeze happens even when trying to show the arguments for one specific PID that I know is safe and normal, e.g.:

foo_user@my_machine:~$ ps 14040
  PID TTY      STAT   TIME COMMAND
14040 ?        D      0:00 ps -aux

(Which also froze in the exact same way and is now pid 22620 in the list above.)

However, running ps with arguments that don't list full process command lines doesn't cause this freeze. I'm able to successfully run ps -u $USER or top -u $USER, get output, and have those processes exit normally.

The frozen processes don't respond to any stdin input, including control characters like ctrlC or ctrlZ that would normally exit or suspend the running process. They also don't respond to any signals; even sending SIGKILL (via kill -9) doesn't make these processes exit.

Note that this is a multi-user system that I do not have superuser access on.

Why would these processes be freezing like this, and how can I list arguments for my processes without having the listing process freeze?


I ran some of the commands suggested by @StephenKitt.

The first command simply gave an error:

foo_user@my_machine:~$ strace -p 8807
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf

The second command revealed that the ps command is, for some reason, still opening and reading every single /proc/*/cmdline, instead of just the specified one.

foo_user@my_machine:~$ strace ps 14040
⋮
⋮
stat("/proc/30825", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/30825/stat", O_RDONLY)      = 6
read(6, "30825 (gvfsd-network) S 1 2650 2"..., 2048) = 186
close(6)                                = 0
open("/proc/30825/status", O_RDONLY)    = 6
read(6, "Name:\tgvfsd-network\nState:\tS (sl"..., 2048) = 1000
close(6)                                = 0
open("/proc/30825/cmdline", O_RDONLY)   = 6
read(6, "/usr/lib/gvfs/gvfsd-network\0--sp"..., 131072) = 70
read(6, "", 131002)                     = 0
close(6)                                = 0
stat("/proc/30849", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/30849/stat", O_RDONLY)      = 6
read(6, "30849 (chrome) S 1 1750 1750 0 -"..., 2048) = 216
close(6)                                = 0
open("/proc/30849/status", O_RDONLY)    = 6
read(6, "Name:\tchrome\nState:\tS (sleeping)"..., 2048) = 1005
close(6)                                = 0
open("/proc/30849/cmdline", O_RDONLY)   = 6
read(6, 

This is the end of this command's output, at which point it froze the same way the other ps commands froze.


Running ps -q $pid -o args does work, listing arguments for the specified PID without freezing. This flag makes ps explicitly avoid reading process files for any process other than the one specified.

7
  • I've seen that happen before in some pathological conditions. Looking at the /proc/pid/stack on the pid of ps or of the process for which it's trying to retrieve information might give you some clue. Also check the kernel logs (dmesg) May 13 at 13:40
  • @StéphaneChazelas I don't have permissions to read that file: cat: /proc/8807/stack: Permission denied May 13 at 13:51
  • 4
    Try as root. As it suggests some form of system failure, you may want to get the system's admin involved if it's not you. May 13 at 13:53
  • 1
    Yes, ps looks at all processes unless you specify pids with -q (pid -q 14040). May 13 at 13:56
  • 1
    @Archemar no, ps -q 14040. See What exactly does ps -p PID do that ps -q PID does not? May 13 at 14:55

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.