-
Notifications
You must be signed in to change notification settings - Fork 2
kore-rpc
ending normally says user-interupted
#317
Comments
The proper fix is to undo #298 , but for that the server needs to handle the |
This is a known issue in the Haskell runtime system which seems unadressed to this day. There appear to be a couple of workarounds like this one: IntersectMBO/cardano-node#3641 However, can't tell whether this would actually prevent the error above from being thrown. |
I think we should keep
If the concern is just the appearance of an error in the logs, we can probably catch |
If there's no simple way to process both |
I believe this is addressed at this point? I haven't seen the error message in logs for a while, and I am indeed comforted by that. |
Closes runtimeverification/kontrol#375. Related: #298, #317 Using `SIGINT` or a [SIGTERM handler](runtimeverification/hs-backend-booster@bc7c1b0) causes some sort of a deadlock in the booster, making Kontrol hang. Based on our experiments, switching to `SIGTERM` seems to fix this issue. The disadvantage, as mentioned by @goodlyrottenapple and @jberthold, is that we won't get the SMT transcript or any other logs that haven't been flushed to file when the SIGTERM is received; however, it would address a major usability issue in view of the upcoming workshop next week, at least as a temporary solution. --------- Co-authored-by: devops <devops@runtimeverification.com>
Closes runtimeverification/kontrol#375. Related: #298, #317 Using `SIGINT` or a [SIGTERM handler](runtimeverification/hs-backend-booster@bc7c1b0) causes some sort of a deadlock in the booster, making Kontrol hang. Based on our experiments, switching to `SIGTERM` seems to fix this issue. The disadvantage, as mentioned by @goodlyrottenapple and @jberthold, is that we won't get the SMT transcript or any other logs that haven't been flushed to file when the SIGTERM is received; however, it would address a major usability issue in view of the upcoming workshop next week, at least as a temporary solution. --------- Co-authored-by: devops <devops@runtimeverification.com>
Closes runtimeverification/kontrol#375. Related: runtimeverification/pyk#298, runtimeverification/pyk#317 Using `SIGINT` or a [SIGTERM handler](runtimeverification/hs-backend-booster@bc7c1b0) causes some sort of a deadlock in the booster, making Kontrol hang. Based on our experiments, switching to `SIGTERM` seems to fix this issue. The disadvantage, as mentioned by @goodlyrottenapple and @jberthold, is that we won't get the SMT transcript or any other logs that haven't been flushed to file when the SIGTERM is received; however, it would address a major usability issue in view of the upcoming workshop next week, at least as a temporary solution. --------- Co-authored-by: devops <devops@runtimeverification.com>
Closes runtimeverification/kontrol#375. Related: runtimeverification/pyk#298, runtimeverification/pyk#317 Using `SIGINT` or a [SIGTERM handler](runtimeverification/hs-backend-booster@bc7c1b0) causes some sort of a deadlock in the booster, making Kontrol hang. Based on our experiments, switching to `SIGTERM` seems to fix this issue. The disadvantage, as mentioned by @goodlyrottenapple and @jberthold, is that we won't get the SMT transcript or any other logs that haven't been flushed to file when the SIGTERM is received; however, it would address a major usability issue in view of the upcoming workshop next week, at least as a temporary solution. --------- Co-authored-by: devops <devops@runtimeverification.com>
Closes runtimeverification/kontrol#375. Related: runtimeverification/pyk#298, runtimeverification/pyk#317 Using `SIGINT` or a [SIGTERM handler](runtimeverification/hs-backend-booster@bc7c1b0) causes some sort of a deadlock in the booster, making Kontrol hang. Based on our experiments, switching to `SIGTERM` seems to fix this issue. The disadvantage, as mentioned by @goodlyrottenapple and @jberthold, is that we won't get the SMT transcript or any other logs that haven't been flushed to file when the SIGTERM is received; however, it would address a major usability issue in view of the upcoming workshop next week, at least as a temporary solution. --------- Co-authored-by: devops <devops@runtimeverification.com>
Closes runtimeverification/kontrol#375. Related: runtimeverification/pyk#298, runtimeverification/pyk#317 Using `SIGINT` or a [SIGTERM handler](runtimeverification/hs-backend-booster@bc7c1b0) causes some sort of a deadlock in the booster, making Kontrol hang. Based on our experiments, switching to `SIGTERM` seems to fix this issue. The disadvantage, as mentioned by @goodlyrottenapple and @jberthold, is that we won't get the SMT transcript or any other logs that haven't been flushed to file when the SIGTERM is received; however, it would address a major usability issue in view of the upcoming workshop next week, at least as a temporary solution. --------- Co-authored-by: devops <devops@runtimeverification.com>
Closes runtimeverification/kontrol#375. Related: runtimeverification/pyk#298, runtimeverification/pyk#317 Using `SIGINT` or a [SIGTERM handler](runtimeverification/hs-backend-booster@bc7c1b0) causes some sort of a deadlock in the booster, making Kontrol hang. Based on our experiments, switching to `SIGTERM` seems to fix this issue. The disadvantage, as mentioned by @goodlyrottenapple and @jberthold, is that we won't get the SMT transcript or any other logs that haven't been flushed to file when the SIGTERM is received; however, it would address a major usability issue in view of the upcoming workshop next week, at least as a temporary solution. --------- Co-authored-by: devops <devops@runtimeverification.com>
Because we're sending
SIGINT
instead ofSIGTERM
to thekore-rpc
, we're getting a weird message even on normal exit:Could we instead, either:
SIGTERM
, orshutdown
message to the RPC server that we call?Related: #298
Related: runtimeverification/haskell-backend#3557
The text was updated successfully, but these errors were encountered: