Why linux chromium have two layered zygote process

[Allen Gu]

As I know,  Linux Chromium  support multiple zygotes,

one  g_generic_zygote , the other is g_unsandboxed_zygote

refer to

https://groups.google.com/a/chromium.org/g/chromium-dev/c/3ChaKKhmIcg/m/g4G1PqpGBQAJ

and 

https://bugs.chromium.org/p/chromium/issues/detail?id=22703

But when I Download the upstream from google daily build output, and run linux chromium. why we also have another two layered zygotes, as show in the following image 

Zygote Process A（pid：6832）  and Zygote Process B (pid:6834),

what's the relationship between the zygote A and zygote B?

[Allen Gu]

another question

I just open one url(https://google.com)

why linux chromium fork three renderer process(pid:6896,6897,6924)

via zygote process(pid:6834)

[K. Moon]

(Note: The screenshot you posted is too small for me to read; consider posting as text instead.)

You can use Chrome's built-in Task Manager to get a better sense for what each process is used for. chrome://process-internals/#web-contents and chrome://discards/graph also have interesting visualizations of process relationships.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/97003592-e1c8-45a2-98db-5c91d3c90dffn%40chromium.org.

[Lei Zhang]

On Linux, all child processes should spawn from a zygote process. For many years, we only had 1 zygote, which was sandboxed. Because it was sandboxed, the zygote could not spawn child processes that required access to system resources that would be blocked by the sandbox. Thus unsandboxed child processes did not spawn from a zygote process, which led to bugs. To fix this, the browser process now creates a second, unsandboxed zygote to spawn unsandboxed child processes.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/520cf659-5864-4920-a21e-e8484df3fbd3n%40chromium.org.

[Allen Gu]

The screenshot that i posted is too small to read， so i post it again as text instead as follow：

  PID TTY      STAT   TIME COMMAND
6659 pts/0    Sl+    0:02  /snap/chromium/1864/usr/lib/chromium-browser/chrome --password-store=basic --url=https://google.com
6831 pts/0    S+     0:00   \_ /snap/chromium/1864/usr/lib/chromium-browser/chrome --type=zygote --no-zygote-sandbox --change-stack-guard-on-fork=enable
6854 pts/0    Sl+    0:00   |   \_ /snap/chromium/1864/usr/lib/chromium-browser/chrome --type=gpu-process --change-stack-guard-on-fork=enable --gpu-preferences
6832 pts/0    S+     0:00   \_ /snap/chromium/1864/usr/lib/chromium-browser/chrome --type=zygote --change-stack-guard-on-fork=enable
6834 pts/0    S+     0:00   |   \_ /snap/chromium/1864/usr/lib/chromium-browser/chrome --type=zygote --change-stack-guard-on-fork=enable
6867 pts/0    Sl+    0:00   |       \_ /snap/chromium/1864/usr/lib/chromium-browser/chrome --type=utility --utility-sub-type=storage.mojom.StorageService
6896 pts/0    Sl+    0:00   |       \_ /snap/chromium/1864/usr/lib/chromium-browser/chrome --type=renderer --display-capture-permissions-policy-allowed --origin-trial-disabled-features=SecurePaymentConfirmation
6897 pts/0    Sl+    0:00   |       \_ /snap/chromium/1864/usr/lib/chromium-browser/chrome --type=renderer --display-capture-permissions-policy-allowed --origin-trial-disabled-features=SecurePaymentConfirmation
6924 pts/0    Sl+    0:00   |       \_ /snap/chromium/1864/usr/lib/chromium-browser/chrome --type=renderer --display-capture-permissions-policy-allowed --origin-trial-disabled-features=SecurePaymentConfirmation  

I have two questions

1.   We already have a  unsandboxed zygote process（pid 6831） as show with blue color ，Why we also have another two  sandboxed  and layered zygotes as show with red color,  ZygoteProcess A（pid：6832）  and Zygote Process B (pid:6834) ？

1.  I just open one url(https://google.com)
   why linux chromium fork three renderer process(pid:6896,6897,6924)

1. via zygote process(pid:6834) ？

[K. Moon]

I believe there's a reason to pre-fork the zygote, as the zygote process has to do some setup that's different from the browser process. Then additional zygote processes are forked from there. I don't recall where exactly this logic lives, though.

I suspect you can answer your own question about why the different renderers exist using Chrome's Task Manager, as it'll tell you exactly what each PID is used for.

[K. Moon]

I looked into this a bit more, and this is part of the user namespace sandbox implementation:

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/sandboxing.md#user-namespaces-sandbox

The first sandbox process acts like PID 1 (the init process), while the second process continues on as the "real" zygote:

https://source.chromium.org/chromium/chromium/src/+/main:sandbox/linux/services/init_process_reaper.cc;l=33;drc=7a6b3e61d8a857b0b2745d936123ef77a2cb15e2

The securi...@chromium.org mailing list might be a good place to ask similar questions in the future.

[Matt Denton]

On Thursday, January 13, 2022 at 10:28:17 AM UTC-8 Lei Zhang wrote:

On Linux, all child processes should spawn from a zygote process. For many years, we only had 1 zygote, which was sandboxed. Because it was sandboxed, the zygote could not spawn child processes that required access to system resources that would be blocked by the sandbox. Thus unsandboxed child processes did not spawn from a zygote process, which led to bugs. To fix this, the browser process now creates a second, unsandboxed zygote to spawn unsandboxed child processes.

On Thu, Jan 13, 2022 at 2:44 AM Allen Gu <guhua...@gmail.com> wrote:

As I know,  Linux Chromium  support multiple zygotes,

one  g_generic_zygote , the other is g_unsandboxed_zygote

refer to

https://groups.google.com/a/chromium.org/g/chromium-dev/c/3ChaKKhmIcg/m/g4G1PqpGBQAJ

and 

https://bugs.chromium.org/p/chromium/issues/detail?id=22703

But when I Download the upstream from google daily build output, and run linux chromium. why we also have another two layered zygotes, as show in the following image 

Zygote Process A（pid：6832）  and Zygote Process B (pid:6834),

what's the relationship between the zygote A and zygote B?

The extra process is created here. The parent process assumes the role of "init" in the new pid namespace, and then does nothing but sit and wait for the child (the "actual" zygote that does all the forking) to die. It doesn't handle anything else, including termination of renderers. I'm not sure whether there's a good reason for it; if there is, I suspect it's either because of some oddity with pid namespaces and their interaction with an init process (e.g. I think you cannot send most signals to an init process), or it's a remnant of the older SUID sandbox.

As you can see, the unsandboxed zygote just runs as the init process and forks things itself, rather than splitting into two processes. This seems to work fine.

Also, to clear up some possible misconceptions, the unsandboxed zygote does not exactly fork unsandboxed processes, it forks processes that *will* be sandboxed later. They just won't be in the renderer's user and pid namespaces.

If you would like to experiment with removing this extra process, contributions are welcome. :)

[Allen Gu]

Thanks all。

As it described in  part of the user namespace sandbox implementation:

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/sandboxing.md#user-namespaces-sandbox

 there are layer-2 sandbox，

The first sandbox process acts like PID 1 (the init process), while the second process continues on as the "real" zygote:

https://source.chromium.org/chromium/chromium/src/+/main:sandbox/linux/services/init_process_reaper.cc;l=33;drc=7a6b3e61d8a857b0b2745d936123ef77a2cb15e2。

But why linux chromium fork multi-renderer process？

I make a test between chromium m81~m83

when i open just on url(www.google.com), it only exist one renderer process in m81

but it exist two renderer processes in m83 (ps:chromium skip m82)

so,  The problem that  there are multi-renderer processes when i just open one url  is caused between m81~m83

but i can't find any  exactly chromium commits related to the problem, and can explain the multi-renderer processes with one url problem

[K. Moon]

Have you looked at the Chrome Task Manager at all? I've repeatedly suggested doing that, and I think that will answer your question. It's hard to say exactly why without knowing exactly what content you're loading.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/ee63084d-782e-4615-8923-aa6e377ce175n%40chromium.org.

[Stefan Zager]

On Fri, Jan 14, 2022 at 6:40 PM Allen Gu <guhua...@gmail.com> wrote:

Thanks all。

As it described in  part of the user namespace sandbox implementation:

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/sandboxing.md#user-namespaces-sandbox

 there are layer-2 sandbox，

The first sandbox process acts like PID 1 (the init process), while the second process continues on as the "real" zygote:

https://source.chromium.org/chromium/chromium/src/+/main:sandbox/linux/services/init_process_reaper.cc;l=33;drc=7a6b3e61d8a857b0b2745d936123ef77a2cb15e2。

But why linux chromium fork multi-renderer process？

I make a test between chromium m81~m83

when i open just on url(www.google.com), it only exist one renderer process in m81

but it exist two renderer processes in m83 (ps:chromium skip m82)

It takes time to start up a renderer process, so chromium always keeps a spare renderer process warmed up and available in case it is needed.

[Allen Gu]

I use Chrome's built-in Task Manager,

chrome://process-internals/#web-contents and chrome://discards/graph

I can show process relationships, and it have a spare renderer process for warm up next renderer process.

But can i disable the spare renderer, and disable the renderer process warm up, and what's related code with the spare renderer?

[Stefan Zager]

On Mon, Jan 17, 2022 at 1:43 AM Allen Gu <guhua...@gmail.com> wrote:

I use Chrome's built-in Task Manager,

chrome://process-internals/#web-contents and chrome://discards/graph

I can show process relationships, and it have a spare renderer process for warm up next renderer process.

But can i disable the spare renderer, and disable the renderer process warm up, and what's related code with the spare renderer?

https://source.chromium.org/chromium/chromium/src/+/main:content/public/common/content_features.cc;drc=c662f11e160976c04682f41941aaeccad92ace48;l=881

[Allen Gu]

OK， Got it， Thanks all very much！