Restarting siblings vs. restarting nieces

[Sid Hussmann]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4BC4E441F1068163.asc
Type: application/pgp-keys
Size: 8529 bytes
Desc: OpenPGP public key
URL: <http://lists.genode.org/pipermail/users/attachments/20230125/d991b06e/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20230125/d991b06e/attachment.sig>