square brackets in output of "ps aux" not matching output of "ps -ejH"
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
square brackets in output of "ps aux" not matching output of "ps -ejH"
Hi guys,
I know it has been discussed on the forum before but it's still very unclear for me...
I read on one of the thread on LQ that processes in brackets [] are kernel threads...or processes that were started by init process...
first of all, are all the processes that were started by init process, kernel threads/processes? I'm abit confused about this one.
Also, why some of the processes that are not listed under "kthread" in the output of "ps -ejH", bracketed in the output of "ps aux"? Do they show different things or how does it work?
I know it has been discussed on the forum before but it's still very unclear for me...
I read on one of the thread on LQ that processes in brackets [] are kernel threads...or processes that were started by init process...
first of all, are all the processes that were started by init process, kernel threads/processes? I'm abit confused about this one.
Also, why some of the processes that are not listed under "kthread" in the output of "ps -ejH", bracketed in the output of "ps aux"? Do they show different things or how does it work?
Thanks
Have you tried looking at the description of the individual flags
in the ps man-page?
Have you tried looking at the description of the individual flags
in the ps man-page?
why do people do that all the time? Maybe I didn't understand or missed something in the man page...I have already mentioned that I'm confused about some stuff...
This is a forum where people ask for HELP...It's not like I've committed a crime....if you have the knowledge and the time, just respond to the question...why are you interrogating? If you do know just answer, if not BROWSE AWAY...
Well ... the best way of helping people is to enable them to help
themselves. Reading the man-page is always the best starting point.
If that's not your idea of help, just ignore my responses. And if
your idea of "getting help" is "being spoon-fed" - who knows, maybe I'll
just ignore your questions in the future...
It points out that PS options/flags relate to Unix, BSD and GNU
Unix requires a leading hyphen
BSD omits the hyphen
GNU requires two hyphens
Just guessing that use of alternative options cause the differences in the bracketing that you have noted
It points out that PS options/flags relate to Unix, BSD and GNU
Unix requires a leading hyphen
BSD omits the hyphen
GNU requires two hyphens
Just guessing that use of alternative options cause the differences in the bracketing that you have noted
Thanks but I've already tried that and it still shows the same thing. Like, say, nfsd in output of "aux" is bracketed, but in output of "ejH" is not listed under kthread:
Kernel Threads
Kernel threads consist of a set of registers, a stack, and a few corresponding kernel data structures. When kernel threads are used, the operating system will have a descriptor for each thread belonging to a process and it will schedule all the threads. Unlike processes, all threads within a process share the same address space. Similar to processes, when a kernel thread makes a blocking call, only that thread blocks. All modern machines support kernel threads, most often via the POSIX threads interface ``pthreads''. Some dedicated parallel machines support kernel threads poorly or not at all. For example, the Blue Gene/L microkernel does not support pthreads.
The purported advantage of kernel threads over processes is faster creation and context switching compared with processes. For shared-memory multiprocessor architectures, the kernel is able to dispatch threads of one process on several processors, which leads to automatic load balancing within the nodes. For parallel programming, threads allow different parts of the parallel program to communicate by directly accessing each others' memory, which allows very efficient, fine-grained communication.
Kernel threads share a single copy of the entire address space, including regions such as global data that may cause conflicts if used by multiple threads simultaneously. Threads can also cause unintentional data sharing, which leads to corruption and race conditions. To avoid this unintentional sharing, programs must often be modified to either lock or access separate copies of common data structures. Several very widely used language features are unsafe when used with threads, such as the use of global and static variables, or the idiom of returning a reference to a static buffer. Especially with large existing codebases with many global variables, this makes kernel threads very difficult to use because in most implementations of kernel threads, it is not possible to assign each thread a private set of global variables.
Kernel threads are considered ``lightweight,'' and one would expect the number of threads to only be limited by address space and processor time. Since every thread needs only a stack and a small data structure describing the thread, in principle this limit should not be a problem. But in practice, we found that many platforms impose hard limits on the maximum number of pthreads that can be created in a process. Table 2 in Section 4 shows the practical limitations on pthreads on several stock systems.
In particular, operating system kernels tend to see kernel threads as a special kind of process rather than a unique entity. For example, in the Solaris kernel threads are called ``light weight processes'' (LWP's). Linux actually creates kernel threads using a special variation of fork called ``clone,'' and until recently gave each thread a separate process ID. Because of this heritage, in practice kernel threads tend to be closer in memory and time cost to processes than user-level threads, although recent work has made some progress in closing the gap, including K42 [5] and the Native POSIX Threading Library (NPTL) and Linux O(1) scheduler.
I read on one of the thread on LQ that processes in brackets [] are kernel threads...or processes that were started by init process...
I have seen this mentioned too - I suspect it is mis-interpretation of the data. And now it's been repeated so often as to become "fact".
I haven't looked at the code, so I can't say for sure.
Here is a quote from the "man ps" on one of my Arch systems that appears relevant
Quote:
Sometimes the process args will be unavailable; when this is happens, ps will instead print the executable name in brackets.
Try your commands with the "c" option and you'll see the difference.
There is a flag in /proc/<pid>/stat that indicates whether that process is a kernel thread, so I'd be inclined to believe the option that supports process hierarchy (-H).
I have seen this mentioned too - I suspect it is mis-interpretation of the data. And now it's been repeated so often as to become "fact".
I haven't looked at the code, so I can't say for sure.
Here is a quote from the "man ps" on one of my Arch systems that appears relevantTry your commands with the "c" option and you'll see the difference.
There is a flag in /proc/<pid>/stat that indicates whether that process is a kernel thread, so I'd be inclined to believe the option that supports process hierarchy (-H).
two explainations from respected and experience authors and administrators...
Uh, what is actually the correct explaination here? I mean, i have read in books that the processes in brackets are kernel threads, but other books says that processes in brackets have the brackets because they are processes which has been swapped out because they are not in active use by the system at that time... so does anyone know for sure what the answer to this actually is? both statements are coming from people with a high knowledge of linux and networking and they have like 19-20 years experience .. i also thought they were kernel threads, but now when a person with 19 years experience which has also written the books on sendmail, qmail, postfix and a dozen other books says that its because the processes are swapped out because they are inactive im getting a little unsure about this...
Might have been true at one time, but now Linux doesn't swap tasks out. That function disappeared years ago - before I even started using Linux.
Pity Linus didn't rename the swap partition/file at the same time.
Might have been true at one time, but now Linux doesn't swap tasks out. That function disappeared years ago - before I even started using Linux.
Pity Linus didn't rename the swap partition/file at the same time.
Ok, the book were they say that processes in square brackets are processes swapped out is from 2008, but i guess they`re wrong then..
Don't believe everything you read. Including here.
I found the changelog for that function disappearing once - if I get bored I might go looking again.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.