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

crash on shared drive becoming unavailable #29

Open
philipstarkey opened this issue Sep 22, 2017 · 1 comment
Open

crash on shared drive becoming unavailable #29

philipstarkey opened this issue Sep 22, 2017 · 1 comment
Labels
bug Something isn't working major

Comments

@philipstarkey
Copy link
Member

Original report (archived issue) by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).


If the shared drive becomes unavailable BLACS crashes and will not do anything until it is restarted.
This is caused by lines 730-736 and 825-831 trowing exceptions that are not caught.

It would be nice if BLACS would handle this in a away that one could resume experiments (after fixing the problem) without needing to restart BLACS.

@philipstarkey
Copy link
Member Author

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).


This is a larger problem than just BLACS - there are many points of failure in labscript suite programs where they will not recover well if either the network drive or the network connection to zlock goes down.

At some point I would like to make a wrapper for accessing files that catches errors and pops up a GUI saying "can't access file/can't contact zlock, retrying in " with a button "retry now". The program in question would hang in the meantime, but for situations where it can't reasonably proceed until it accesses the file/zlock, that's really all that can be done, and prevents the program from crashing hard if there is a minor network mishap.

Then for files where failure is an option, exceptions should be caught and dealt with on a case-by-case basis, for example, how lyse marks inaccessible files as such and ignores them. But a first port of call would be auto retrying with the dialog - definitely better default behaviour than a hard crash.

It's on the todo list!

@philipstarkey philipstarkey added major bug Something isn't working labels Apr 5, 2020
Loki27182 pushed a commit to Loki27182/blacs that referenced this issue Oct 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working major
Projects
None yet
Development

No branches or pull requests

1 participant