2

today I found something strange about the /proc folder. There is a PID (7825) which I cannot see as a running process via ps, also I cannot see the process id when I make ls /proc BUT I can see it with ls /proc/7825 and also can cd into it. Here the outputs:

# ls /proc

...
dr-xr-xr-x   9 xxxxxxx         xxxxxxx             0 May 16 20:57 7812
dr-xr-xr-x   9 xxxxxxx         xxxxxxx             0 May 16 20:52 7820
dr-xr-xr-x   9 root            root                0 May 16 20:52 7836
dr-xr-xr-x   9 root            root                0 May 16 20:52 786
dr-xr-xr-x   9 xxxxxxx         xxxxxxx             0 May 16 20:57 7923
dr-xr-xr-x   9 xxxxxxx         xxxxxxx             0 May 16 20:52 7924
...

ps aux | grep [7]825

[EMPTY RESULT]

ls /proc/7825
attr    clear_refs  coredump_filter  environ  fdinfo   largest_task  make-it-fail  mem        mountstats  oom_adj        pagemap      root       setgroups  stat    syscall        timerslack_ns  weight
auxv    cmdline     cpuset           exe      gid_map  limits        map_files     mountinfo  net         oom_score      personality  schedstat  smaps      statm   task           uid_map
cgroup  comm        cwd              fd       io       loginuid      maps          mounts     ns          oom_score_adj  projid_map   sessionid  stack      status  time_in_state  wchan

Why is this PID available for ls /proc/7825 but doesn't show up in the ps os ls /proc?

This is quite critical for my program, because I have to check if a certain PID (of the previous run) is still running (check if /proc/[LAST_RUN_PID]/exe exists). If so, I consider the previous run as "still-running". Today we had the issue, that the file /proc/7825/exe still exists (for hours) even if there is no program running.

Can somebody elaborate why/how this happens?

guenhter
  • 163
  • That's it: 
    # ps -AL | grep 7825
 7803  7825 ?        00:00:00 gmain

    If you post this as question, I'll mark it as the solution.

     – guenhter May 17 '21 at 08:19
  • 2
    Just FYI: PID can be reused by other processes/fork/etc, so they aren't unique per se...so if you base your program/workflow around a specific PID instead of an actual program's PID (eg: grep the program name -> then grep the ID/PID of said program, which could have changed, etc) then you might see some other surprising thing...although you might be aware of that but just want to make sure you know – Nordine Lotfi May 17 '21 at 08:29
  • @NordineLotfi thx. This is a really good point and I have to consider this as well. – guenhter May 17 '21 at 08:31

1 Answers1

5

ps on Linux takes its information from /proc so their information can't really differ. Even if incorrect pid/mount namespace setup means that /proc represents information not from the current pid namespace, ps will report the same incorrect information.

Here, it's likely that 7825 is a thread of some other process and you'd see it in the output of ps -ALf, where -L tells ps to report about all threads (light-weight processes), not just processes.

Stéphane Chazelas
  • 544,893
  • @StephenKitt, I'd expect it's possible if you switch pid namespace and not mount namespace. See for instance sudo unshare -fp sh -c 'echo "$$"; ps' – Stéphane Chazelas May 17 '21 at 08:36
  • @StephenKitt, see also the --mount-proc of unshare(1). Just before running the program, mount the proc filesystem at mountpoint (default is /proc). This is useful when creating a new PID namespace. It also implies creating a new mount namespace since the /proc mount would otherwise mess up existing programs on the system. The new proc filesystem is explicitly mounted as private (with MS_PRIVATE|MS_REC) – Stéphane Chazelas May 17 '21 at 08:45
  • Indeed, I was under the impression that /proc only cared about the pid namespace... – Stephen Kitt May 17 '21 at 08:46
  • Ah, it looks up the pid namespace of the /proc i_sb. – Stephen Kitt May 17 '21 at 08:51