How can I determine if a process is a system process?

Question

I'm reading the /proc directory (or pseudo-fs) to find all processes. I'm getting the information I need from /proc/[pid]/status but there's something else I need. Is there any way to figure out which processes are critical to system? for example using parent-pid or UID of the process?

By system process, I mean processes that would otherwise exist on a fresh installation of the OS, and before installing any application or services. This might not mean kernel threads, or system processes at all, but to sum it up, I mean processes, that their termination, would disrupt the fundamental structure of the system.

PS. I'm working on an android app, but since this part is done using pure Linux file system I asked it here and I don't suppose that there would be any different.

Solution 1

If you have htop you can press Shift+k to toggle the display of kernel threads. If you press F5 for tree mode, they should all appear as children of kthreadd.

There are some visible differences between a kernel thread and a user-space thread:

• /proc/$pid/cmdline is empty for kernel threads - this is the method used by ps and top to distinguish kernel threads.

• The /proc/$pid/exe symbolic link has no target for kernel threads - which makes sense since they do not have a corresponding executable on the filesystem.

More specifically, the readlink() system call returns ENOENT ("No such file or directory"), despite the fact that the link itself exists, to denote the fact that the executable for this process does not exist (and never did).

Therefore, a reliable way to check for kernel threads should be to call readlink() on /proc/$pid/exe and check its return code. If it succeeds then $pid is a user process. If it fails with ENOENT, then an extra stat() on /proc/$pid/exe should tell apart the case of a kernel thread from a process that has just terminated.

• /proc/$pid/status is missing several fields for most kernel threads - more specifically a few fields related to virtual memory.

The Above answer from Identifying kernel threads

Another way to distinguish kernel threads from other process is to run top -c. From the top manual:

3. COMMAND -- Command Name or Command Line
Display the command line used to start a task or the name of the associated program. You toggle between command line and name with 'c', which is both a command-line option and an interactive com‐ mand.

When you've chosen to display command lines, processes without a command line (like kernel threads) will be shown with only the program name in brackets, as in this example:
[ mdrecoveryd ]

Running ps aux also displays processes that were launched without a command in square brackets ( and will have an empty /proc/[pid]/cmdline file ).

Example:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        19  0.0  0.0      0     0 ?        S<   Mar02   0:00 [kworker/1:0H] 

See package procps-3.2.8 file /proc/readproc.h.

// Basic data structure which holds all information we can get about a process.
// (unless otherwise specified, fields are read from /proc/#/stat)
//
// Most of it comes from task_struct in linux/sched.h

Solution 2

You cannot. “System process” is not a well-defined notion. “Critical to system” is not a universal, yes-or-no property.

I'm writing this post on a desktop PC. It has Apache installed, but it is not “critical to system” on this machine — I only use it occasionally to test things. On the other hand, on a public- or enterprise-facing web server, Apache would be essential. Conversely, an X server is not critical on most servers, but on a workstation, it's essential.

There is no shortcut. If you want to know whether killing a process will break anything, you need to understand what the process is doing. If you don't know what a process is doing, assume that it is critical.

“Processes that would otherwise exist on a fresh installation of the OS, and before installing any application or services” is not a well-defined concept either. Services may be critical on a particular system even if they aren't part of the default installation (e.g. Apache). Conversely, services may be included in the default installation but not be critical on a particular system (e.g. a network management service on a system with no network connection).

On Android, which is not a Linux system (it's a different system using the Linux kernel), you can call anything running off /system a “system process”. This definition is somewhat meaningful on Android, unlike Unix, because it clearly separates the base system from user-installed applications. The base system includes preinstalled apps (phone, Gmail, etc.), with a different selection depending on the phone vendor (manufacturer or network operator). A twist to this definition is that apps running off /data but for which an entry in /system/app exists are also “system” apps by this definition, just ones that have been upgraded.

Comments

[iyrin]

Peep this stackoverflow.com/questions/12213445/identifying-kernel-thre‌​ads

[iyrin]

I believe the term "system process" is ambiguous. I assumed this included processes such as kernel threads, but it often refers to any daemon or background process. For the latter, yes you can see if a process is a background process, but that didn't sound like what you are asking. Could you be more specific?

[Milad.Nozari]

Thanks, could you please indicate what each column means?

[kallaguntaashok]

@goldilocks Yes, there is no pid 0. But if PPid = 0 that means pid has no parent pid therefore it is system process. from ps -fe: root 1(pid) 0(ppid) .... /sbin/init

[goldilocks]

There is only one process with a ppid of 0, and that is init, because it is the only process without a parent. All other processes are descended from it and have a ppid >= 1.

[kallaguntaashok]

@goldilocks Not only one process has ppid of 0. Kernel threads also have ppid of 0.

[goldilocks]

Kernel threads are not processes. A process is a userland entity.

[kallaguntaashok]

@goldilocks It doesn't matter they're not processes. They show in ps and are present in /proc.

[kallaguntaashok]

@goldilocks I did not said threads are processes. I merely said they have ppid equal to 0.

[Milad.Nozari]

Does this mean that kernel threads have a pid in /proc ?

[goldilocks]

Alright, fair enough. They do have PIDs, which is a bit confusing. All this is sort of tangential though, because there is no real answer to this question unless you define "system process". You've done it in two distinct, arbitrary ways: 1) That processes owned root are system processes. That is meaningless, and false. 2) That processes with a ppid of 0-2 are system processes. That is a bit more meaningful, but still pretty arbitrary since any process can end up with a ppid of 1. So you are promising the OP something that is not true.

[goldilocks]

...unless every process is a "system" process, which does make sense -- but then it is a pointless qualifier.

[kallaguntaashok]

@goldilocks Actually i like to think i gave practical answer, contrary to your non-answer.

[iyrin]

They do have a pid as can be seen in htop or top or ps.

[goldilocks]

If someone asks "Which floor of the building is Cleveland on?", you do not say, "You can see it from the 11th floor." You say, "Cleveland is not that kind of thing". The only critical entities are the kernel and init. Everything else is arbitrary and optional. If that's a "non answer", I give up. Believe whatever.

[Milad.Nozari]

So far so good. There's only one thing left. As I mentioned I want to determine that by reading the info in /proc, and as far as I know, top gets (most of) its info from there too. How does top determine the value for command?

[Milad.Nozari]

Yes, I've already got that part. But I'm talking about the value under the command column in top when you hit c. For example for android emulator it's /home/mnvoh/Android/Sdk/tools/emulator64-x86 -avd API17_AND4_2_2_4_7IN_720p -netsp+ but for kworker, which you mentioned, it's [kworker] or [kworker/3:0]

[iyrin]

See the edit to the answer above and also see Gilles's answer here. stackoverflow.com/a/14176059/2407742 I believe the name field of /proc/<pid>/status is your only option when looking at a kernel thread via proc because they are not started with a command. Therefore, /proc/<pid>/cmdline is empty.

[Milad.Nozari]

Your last paragraph had a really good point. I tried to read the /proc/[pid]/exe symlink, and see if that could be used, but unfortunately for any other process than the process of my own app, it requires root permissions.

[Milad.Nozari]

I think I'm gonna be able to use this empty cmdline. Thanks

[iyrin]

Thanks for the edit. Yes, the lack of an executed command seems to be one of the keys in determining what type of thread it is.