Ticket #2 (closed enhancement: fixed)

Opened 2 years ago

Last modified 1 year ago

Notebook locking

Reported by: wstein@gmail.com Assigned to: boothby
Priority: major Milestone:
Component: notebook Keywords:
Cc:

Description

Currently it is possible to run two SAGE notebooks on the same directory, which is potentially VERY VERY bad. It would be better if when a SAGE notebook server starts up it checks for the presence of a lock file. This file would contain the pid of a running SAGE notebook process -- if the file and that process exist, then the notebook won't start. When the notebook finishes it should delete that lock file.

Change History

09/11/2006 09:26:49 AM changed by justin@mac.com

A thought: PIDs live in a fairly small space, so it might be worth doing some kind of check to verify that the process corresponding to the PID is a SAGE notebook process.

Alternate approach: instead of just bailing, ask the user whether to continue (and remove the existing lock file), or quit. That puts the burden on the user instead of the programmer, but the results may be better.

(in reply to: ↑ description ; follow-up: ↓ 3 ) 09/14/2006 02:24:25 PM changed by boothby

Rather than keep a PID, a more robust solution would be to write the URL to the notebook in the lockfile. Upon startup, the server would send a request to that URL -- if there's already a running server, just return.

If we also stored the PID, we could attempt to kill nonresponsive servers.

(in reply to: ↑ 2 ) 01/23/2007 09:29:15 PM changed by nbruin

One could end up with an NFS filesystem and notebooks running on distinct machines. If the port listened on is only a local one on machine A then sending a request from machine B will not confirm that the process is still running.

This is a bad thing to happen, but not unlikely if someone has sage installed in their homedir and moves from machine A to machine B.

08/23/2007 04:01:54 AM changed by mabshoff

  • owner changed from somebody to boothby.
  • component changed from basic arithmetic to notebook.

08/23/2007 10:30:56 PM changed by was

  • status changed from new to closed.
  • resolution set to fixed.

This was fixed decades ago!