Dear Genodians,
I noticed a behavior that I would like to understand. Let's assume we have the following parent-child relationship of a sub-system, omitting some ancestors for simplicity:
``` . └── init ├── fs │ ├── init │ │ └── rump │ ├── fs_mgr │ └── report_rom ├── fs_client1 └── fs_client2 ```
In this example, the config for the first `init` is written via the depot query/deploy mechanism. Thus, `fs`, `fs_client1`, and `fs_client2` are pkg archives. The `runtime` file from pkg archive `fs` contains a management component `fs_mgr` that generates an `init` config which starts a `vfs` server with a `rump` plugin within that `init`. For context, we use the `fs_mgr` to instrument it to start `fsck` or `mkfs` depending on its configuration. But that's not relevant right now.
Let's also assume the routing is valid so that `fs_client1` and `fs_client2` are up and running, and they both consume the `File_system` session provided by `rump`.
Now to my observation:
When I restart `fs` by incrementing its version attribute in the deploy file, `fs`, `fs_client1`, and `fs_client2` all get restarted. That is what I would expect.
However, the behavior is different when I instrument the `fs_mgr` to restart `rump`. Most of the time, both `fs_client1` and `fs_client2` don't seem to notice.
Is this behavior by design? Is `init` designed to behave differently regarding client/server dependency when siblings get restarted vs. when a niece is restarted?
Is there a way to instrument `fs_mgr` to write an `init` config, so that `fs_client1` and `fs_client2` get restarted?
Granted, I observed this in a more complex scenario. I once had the following errors when restarting `rump` on `arm_v8a/base-hw`:
``` Kernel: init -> init -> fs_client1 -> ep: cannot send to unknown recipient ... Kernel: Cpu 0 error: re-entered lock. Kernel exception?! ```
Would it make sense for me to create a simplified scenario of it to dig into this behavior further?
Kind regards, Sid