Where does it go? Are kthread and ksoftirq the next two threads on all boxes or just mine ?

It doesn't go anywhere. Those processes show on my system too - I imagine they are kernel related.

You are seeing two entirely different things:

init (a.k.a. "Process #1") is a user-level process that is hand-built by the kernel during system startup ... and that is never allowed to die. It performs fundamental services for the system, including being the "grim reaper" of any other user-land process whose parents have died. (The orphans are briefly parented to this process so that it can clean them up, thereby neatly avoiding what would otherwise be a special-case of "cleaning up a process that has no parent." The processes are given a parent, and that parent is never allowed to not be there.)

(If init ever does die, you get the mis-named message: "Kernel panic ... tried to kill init." That's what that message actually means.)

Meanwhile ...

The various processes and threads that you see whose names begin with the letter k and which are owned by uid #0 are: kernel threads. These are, literally, "parts of the kernel," which are executing (under very special and highly-privileged conditions ...) "as 'ordinary,' 'pre-emptible,' processes." This allows them to be asynchronous, as they need to be to do whatever-it-is that they do, while "bending as few rules as possible." These "parts of the kernel" are able to run "under the auspices of the kernel," and thus to avail themselves of many of the kernel-provided services that are available to userland, without being "a massive special-case."

1 members found this post helpful.

Thanks for the great explanation. I'm trying to understand this a little better. Books have vague info. init is still the first kernel thread correct? And kxx are threads that init initialized. when I say where does init go, I am referring to CPU_idle. Does init go here and call a function then become k_init?

Fwiw: systemd will be process 1, pretty much from here out. I personally wouldn't spend too much time learning about init, since it's in the process of being deprecated.

1 members found this post helpful.

Thanks. I'm guessing thus is why my box didn't match up to the books I an using. Systemmd seems to change be more relevant. A but off topic but is there a way I can edit start_kernel() and setup.c in a kernel I didn't compile myself? I don't have source/arch/x86/kernel/setup.c.

sysvinit is not deprecated. systemd is just one of a number of alternatives. It may end up that systemd becomes the most commonly used and supported, but that doesn't deprecated any of the others any more than Ubuntu deprecates debian, or mint deprecates ubuntu.

Besides, unlike systemd, the time needed to learn about sysvinit is trivial, so why not learn it.

1 members found this post helpful.

No, thats fine. I agree with you. Learning both can't hurt.

But, I disagree with the first part. First off, I didnt say it IS deprecated, I said that it is in the process of BEING deprecated. And this is true. You can mince words and say that systemd is an 'alternative' but the fact is that it is replacing sysvinit as the standard.

Most of the major distros have already switched, and more will follow suit.

Debian, Ubuntu, RHEL, Fedora, Suse,.. All systemd. And since MOST distros are based on these, you can bet that within X years, systemd will be the standard. Sysv will be unmaintained and forgotten eventually.

The argument can be made that 'alternatives' will spring up and be used. And this is true. But they will NOT be in the majority, and will not be considered the STANDARD.

So I believe that my suggestion to concentrate on Systemd is a good suggestion based in reality. But as mentioned, learning sysv can't hurt, especially since you will still run into systems that use it for a long while. For this i suggest debians outstanding guide: https://www.debian.org/doc/manuals/d...e/ch03.en.html

1 members found this post helpful.

If anyone us interested.en.m.wikipedia.org/wiki/Systemd. Has a nice summary of why systemd is a pain.

Be that as it may ... (ahem), the fact remains that the Unix/Linux system does rely on certain user-land processes to perform essential-to-the-system services. These processes are "magically created" by the kernel during startup, and the system will grind to an immediate halt ("kernel panic!") if they ever die or fail to start.

And, separate from this idea, there are also "fully asynchronous parts of 'the kernel itself,'" running truly "in kernel space," but thereby able to "wait on" things, or to start I/O operations and sleep until those operations complete, and so on. (Which things are otherwise quite difficult for "the kernel" to do, because of its very unique position.)

You should always keep in mind that "not all Unix/Linux-es are created equal," and so you might at any time find yourself working on an older system that does it one way, and a newer system that does the same thing another way, and the two of them might well be sharing rack-space with one another. In this business, it's important to be aware of both the older and the newer. (Preferably, without judging them . . . )

1 members found this post helpful.