Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crashes with internal error if capnp-secrets/ directory doesn't exist #339

Open
shonfeder opened this issue Jul 10, 2024 · 1 comment
Open

Comments

@shonfeder
Copy link
Contributor

shonfeder commented Jul 10, 2024

$ dune exec -- opam-repo-ci-local --confirm harmless --repo $REPO_PATH --branch $BRANCH_NAME --capnp-address tcp:127.0.0.1:5001
opam-repo-ci-local: internal error, uncaught exception:
                    Sys_error("./capnp-secrets/secret-key.pem: No such file or directory")
                    Raised by primitive operation at Stdlib.open_out_gen in file "stdlib.ml", line 331, characters 29-55
                    Called from Capnp_rpc_unix__Vat_config.write_whole_file in file "unix/vat_config.ml", line 53, characters 11-84
                    Called from Capnp_rpc_unix__Vat_config.init_secret_key_file in file "unix/vat_config.ml", line 66, characters 4-34
                    Called from CamlinternalLazy.do_force_block in file "camlinternalLazy.ml", line 49, characters 17-27
                    Re-raised at CamlinternalLazy.do_force_block in file "camlinternalLazy.ml", line 56, characters 4-11
                    Called from CamlinternalLazy.force_lazy_block in file "camlinternalLazy.ml" (inlined), line 78, characters 27-67
                    Called from Capnp_rpc_unix__Vat_config.hashed_secret in file "unix/vat_config.ml", line 38, characters 54-77
                    Called from Capnp_rpc_unix__Vat_config.derived_id in file "unix/vat_config.ml" (inlined), line 96, characters 15-30
                    Called from Dune__exe__Capnp_setup.run in file "service/capnp_setup.ml", line 20, characters 21-69
                    Called from Dune__exe__Local.setup_capnp in file "service/local.ml", line 12, characters 2-69
                    Called from Dune__exe__Local.main in file "service/local.ml", lines 41-42, characters 4-39
                    Called from Cmdliner_term.app.(fun) in file "cmdliner_term.ml", line 24, characters 19-24
                    Called from Cmdliner_term.term_result.(fun) in file "cmdliner_term.ml", line 48, characters 25-32
                    Called from Cmdliner_eval.run_parser in file "cmdliner_eval.ml", line 35, characters 37-44

I hit this running local, but I expect the same behavior would happen running the main service. IMO, the best behavior would be to create the needed directory if doesn't already exist: this will make set up and deployment simpler, but at least, it should handle the error and report the issue correctly.

(This is easy to fix, but I'm opening an issue so as not to pollute unrelated work with this fix.)

This is probably the place where the logic should be fixed:

let run ?listen_address ~secret_key ~cap_file = function
| None -> Lwt.return (Capnp_rpc_unix.client_only_vat (), None)
| Some public_address ->
let config =
Capnp_rpc_unix.Vat_config.create
~public_address
~secret_key:(`File secret_key)
(Option.value listen_address ~default:public_address)
in
let rpc_engine, rpc_engine_resolver = Capability.promise () in
let service_id = Capnp_rpc_unix.Vat_config.derived_id config "ci" in
let restore = Capnp_rpc_net.Restorer.single service_id rpc_engine in
Capnp_rpc_unix.serve config ~restore >>= fun vat ->
Capnp_rpc_unix.Cap_file.save_service vat service_id cap_file |> or_die;
Logs.app (fun f -> f "Wrote capability reference to %S" cap_file);
Lwt.return (vat, Some rpc_engine_resolver)

@shonfeder shonfeder self-assigned this Jul 10, 2024
@mtelvers
Copy link
Member

I hit this running local, but I expect the same behavior would happen running the main service.

This is less of a concern for the main service as we are deploying with Docker. We need to persist /capnp-secrets so it will be mounted as a Docker volume. This will cause Docker to create the mount point/directory for us.

@shonfeder shonfeder removed their assignment Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants