Linux – Redirecting Output to File

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

You missed the most important point, shell redirection is applied in order from left to right.

In:

{ 2>&3 "$@"& } 3>&2 2>/dev/null

The whole group command is run with:

• File descriptor 3 => standard error, which is terminal at this time.
• File descriptor 2 (Standard error) => /dev/null

So when command inside grouping run:

• Standard error => File descriptor 3, which is pointed to terminal.

So if "$@"& print anything to its standard error, the output is printed to terminal.

For your concrete cases:

{ grep warning system.log& } 2>/dev/null

{ grep warning system.log& } runs with standard error is pointed to /dev/null. grep does not override any redirection so its standard error is the same with {...}, and is redirected to /dev/null, you got no output to terminal.

In:

{ 2>&3 grep warning system.log& } 3>&2 2>/dev/null

grep's standard error is redirected to file descriptor 3, which is pointed to terminal as explained above, so you got output to terminal.