Service denied when server is updated

[Norman Feske]

Hi Stefan,

> I observed that when a runtime configuration with a app already present
> (downloaded and unpacked) accessing a service on new server (version) is
> deployed, the app gets a Service_denied exception while the new server
> (version) is being downloaded, verified or unpacked.
> 
> Wouldn't it be better to start all components in the runtime
> configuration only when all possible downloading is complete?

the sculpt manager is already supposed to work that way. A subsystem is
started only if all children referred to the subsystem's routing rules
are present in the runtime (by looking at the children's names in the
report/runtime/state report). Otherwise, the sculpt manager displays
messages like "<subsystem> requires <server-name>" in the "Runtime"
dialog and defers the start of the subsystem.

I guess that you hit a corner case not properly handled so far. Can you
confirm that my understanding of the situation is correct? You already
had a server running. Now you changed the pkg version but keep the
server's name the same. This triggers the download of the new pkg. While
downloading, you start a client. Unexpectedly, the client starts before
the server's new pkg is ready. It could very well be that such an
on-the-fly version update is the problem. To investigate, I would very
much appreciate a simple sequence of steps (preferably using the RAM fs)
to reproduce the behavior.

> Otherwise we either need to make components tolerant to Service_denied
> exceptions or detect such error conditions and restart the runtime entirely.

We should better address the corner case. ;-)

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20180707/5774cbed/attachment-0001.sig>